2012-2013 - A banner year for OS-Cubed, Inc.

The last year has been an amazing one. OS-Cubed has:

• Produced a dashboard for sales performance for a major national firm using MS-SQL, office applications, and automation scripts
• Assisted with building web based administrative tools for an enterprise print management dashboard using C# and .Net
• Implemented a major new ecommerce site using DotNetNuke
• Created dozens of brochure sites using DotNetNuke
• Created custom product choice wizards for 2 international companies for their DotNetNuke site - one of which has gotten national recognition and will be featured on their distributors and resellers websites.
• Hosted over 100 websites for clients - without a single failure or downtime beyond normal maintenance.
• Provided hosting services for a web based human resource career application co-developed by us that services tens of thousands of employees world wide for a major international firm
• Installed hundreds of new machines at client sites
• Implemented virtual servers
• Supported users
• Created an application to manage bar code inventory items and update their status in a proprietary ERP system
• Assisted in implementing a HIPAA compliant EMR system
• Protected thousands of users from viruses
• Migrated hundreds of users to Office365 and Google Apps in the cloud
• Implemented a complete redesign of a major medical information website
• Implemented a successful prototype of a fashion website for an entrepreneur who has since leveraged that with major funding
• Implemented sophisticated SSL and remote access for multiple clients
• Managed technology transitions and expansions for dozens of local clients
• Assisted multiple not-for-profit boards with their websites
• Helped organize and handle technology for the Eyes on the Future Event
• Helped an organization with limited funds continue to support their 60 workers with very old technology

What can we do for you?  Let us know what kind of problem you have to solve and we'll help you solve it.

What you probably don't know about Microsoft's new direction

and why it's important for every Microsoft Developer to understand it...

Microsoft has finally let the other shoe drop on how their new Office/Cloud/Windows 8 strategy is going to work by releasing the details of how Office 2013/365 will be licensed and sold - and it's not just a shoe it's a hiking boot - landing with a big THUD.

There are some important new ramifications about how the entire thing will work - and it's important for you as a developer to understand how that changes what is still the predominant IT ecosystem on the planet.  Let me apologize now to the Linux, Apple and Android developers - this article is not for you - it's for those of us who have been working on Microsoft Apps for the last 30 years.

Let's start with a little history.  Back in the late 70's and early 80's a revolution happened.  Until that point computers were large, relatively complex beasts, controlled by a corporate entity (because they were too expensive for mere individuals to buy) and had one processor, one set of ram, and one set of hard drives shared by dozens of users through a terminal.  This had advantages and disadvantages.  It was easy to control software and access to that software, and easy to manage since everyone shared the same tools.  Of course you couldn't easily take your work home with you (you might consider that a good or bad thing) and the applications were very expensive and monolithic since it required the developer to have equivalently expensive tools to create the software.  In the late 70's personal computers peeked their way into the American home.  Initially crude and difficult to use - but relatively inexpensive compared to their mainframe counterparts - they created a revolution.  Suddenly you could purchase a system that would let you perform powerful calculations and perform difficult tasks in  your home.  More importantly, through the advent of the business PC you could have the same platform at work as you used at home and carry data back and forth on a portable storage device.  Also importantly - you could purchase a system to develop for this new platform that didn't cost an arm and a leg - which meant that new software and software improvements increased at an exponential rate.

Since that time we added in the ability to access your computer over the internet - and for computers to have access to shared data on the internet.  At the same time - through some serious investment in infrastruture, it became cheaper to get storage, processor time and bandwidth through major services like Windows Azure, Amazon AWS and other huge interconnected networks.  So in a sense we're back where we started from.  Our current devices are very complex and independent, but we're becoming more and more reliant on apps and storage that run in the cloud - simplifying the requirements for what our personal devices need to have.  Suddenly a tablet running a run of the mill low power processor can leverage gigabytes of data, bandwidth and the processing power of thousands of processors.  This means that - down the road - assuming we continue to live in a connected society our applications are going to become more and more like the original mainframe apps of the 70's and 80's.  Instead of buying machines with gigabytes or terabytes of  local storage we're going to be buying a simple inexpensive machine that leverages that cloud power.   Our operating systems need to be less complex because the heavy lifting isn't handled at the desktop any more, or even at the local server level.

With Windows 8 and Office 365 subscription services Microsoft has moved from the "software as a license you buy model" (which hasn't been eliminated yet - just deemphasized) to the "software  you subscribe to and get as needed" model.  An individual can now - for $100/year - buy any kind of device they want - phone, tablet, pc, laptop or something not even invented  yet, install office software on up to 5 devices they own, use a simpler version of that software on the web, get 27gb of cloud document storage to use or share with whomever they want (plus each of the other 4 users gets 7 gb of storage for a total of 55GB of available shareable storage for $100/year).  They get an hour of free Skype talking and sharing a month.  They get the latest version of office, allowing frequent updates to add functionality without the expense of giant new releases.  They get streaming of the software to a PC that isn't even licensed for Office to edit a document assuming the target is running Windows 7 or 8.  On the corporate side the same thing can be acquired (with slight variations in capability) for $240/year/user for enterprise users or $150/year/user for small businesses - and on the corporate side they add in sophisticated sharepoint capabilities and active directory management (doing away with the need for an active directory server, or minimizing it's need to being just a local extension of the cloud).  For $72/month they can have the same thing, without the locally installed office licenses.  In addition, with either a corporate or Live account your settings, files, and preferences follow you from machine to machine - even across platforms.  By the end of this year Gartner Group estimates that the PREDOMINANT way that websites will be accessed is via a phone or tablet.  It will outstrip desktop and laptop access - in 2013.  That's this year folks.

So what does that mean for you as a developer?  It means that Microsoft means to make cloud storage and apps it's end game - not just an add-on, and the day of the local server - and even the super powerful end user system are slowly - but surely - ending.  And if you think - well we'll just move to another platform - think again.  The largest competing platforms for end-user computing are moving in the same direction.  Apple (of course) saw this coming years ago and has quietly started phasing out desktop and laptop machines in favor of tablets and other simpler less expensive devices.  Google's play in the Android market focuses strictly on low powered machines that leverage the cloud.  Linux for the desktop?  Nice OS but used only by technogeeks so far. In the next 2-4 years you're going to see a huge shift away from expensive powerful, complex to manage servers and systems in your office or home and towards low priced, low powered systems that leverage the cloud.  And once they go cloud they won't be going back.  Don't believe me?  The only way to deploy a standalone Access application in Access 2013 is to deploy it to Azure and Sharepoint.

So what can you do as a developer?  For one - learn a cloud based system and leverage it's power - now.  I don't care if it's AWS, Azure, SharePoint or some other platform - but you should start to figure out how they work, how to make your apps operate efficiently and actively over a not-always-reliable internet connection, and how to make them scale so that you don't have to sell additional licenses to get additional power out of them.  It also means designing systems - whether they be apps, websites, or whatever - to adapt to a huge variety of interfaces and screen sizes - everything from hand-held phones to 50" 3d High Definition living room monstrosities.  They need to adapt to all sorts of interaction interfaces - the old fashioned keyboard, the mouse, the touchpad, the touchscreen, and the "gesture based" interfaces like the Kinect.  It means that data becomes a mix of BYOD storage (Bring Your Own Data) and corporate cloud storage - and how will you manage that and protect the privacy and security of data when it's easy to copy things from corporate sources into a user's private data store in the cloud.

It also means you should start to explore web and cloud based development tools. That quad core dev machine on your desk may well go away someday - and you need to be ready to use some of the new and sophisticated web based tools for software development in project management, compilation, version control, etc.  The distributed nature of today's collaborations will make that a must.

What happens if you don't?  Well how long did terminal based apps last once the PC was out?  How long did non-graphical DOS based apps after Windows came out?  How long did non-web based apps last after the internet took over?  You have some time - this isn't happening overnight.  But it IS happening and if you don't adapt there will be a day when you wake up and find your app or skills irrelevant.  And that day is approaching.

PS - if you're interested in migrating to the cloud and leveraging Office 365 OS-Cubed is a cloud expert - we can help you with migration, support and leveraging your existing infrastructure while using the cloud efficiently. 

Mobile platforms slowing the production of new PCs

In a recent post from the NY Times they featured an article about how portable devices such as phones and pads have cut deeply into the market for processors for PCs and Laptops - except in the area of processors for large server type systems.  While I'm excited about the opportunities that mobile and lightweight platforms offer I fear that in the long run this trend could significantly damage the development of bigger and better and more powerful personal computer systems.

It's the platform right?

One of the challenges of working with entrepreneurs as clients is that their methodology, purpose and culture for building software are different from your average everyday business or web client.  OS-Cubed has built their methodology, culture and tools around being able to service the entrepreneurial client.  In our case, since we are a small group - we chose ONE platform to support (DotNetNuke on IIS with a MS SQL Back End).  We didn't choose that casually.  We wanted to remain in the well supported (from a developer and a client's point of view) paid .NET development arena.  We wanted to build on software for the back-end that was scalable and reliable.  We wanted to build on software (on the front end) that was open source and optionally free.  And we wanted something that wasn't so proprietary that we couldn't hand it off to another team when the time came.  We also wanted a platform we were experts in hosting - as well as configuring.  We've done things with DNN not even Facebook or Twitter have done - and we did it all on a shoestring budget compared to those sites.
A lot of times our clients end up in our shop because they've gone through one, two - even three or four - developers who have let them down.  They tried the cheap route with programmers from India.  They tried the expensive route with high end business consultants.  They tried hiring "the guy down the street" or the guy from Belarus to build software for them.  Frequently these forays are wretched failures - the entrepreneur-developer bond is a very specific one and if either side doesn't understand how the other thinks and works - you can end up with a real disaster.

Recently a customer came to my office (through a local referral) who was a perfect match for us - they had a site that was created by at least 4 different programmers doing different tasks (in this case all badly or with the wrong tools).  They were ALREADY ON DNN!  Their product was in the educational marketplace - awesome I already have an educational entrepreneurial client so I know the culture and subject matter.  We didn't even need to convert them to the platform, just fix what had been done wrong and adapt it. 
They had some simple, easy to repair (if you know what you're doing) systemic problems that were bringing their site down and making it unreliable, and they were on GoDaddy for hosting - possibly one of the worst hosts in the world.  Amazingly though we were able to take them from a wretchedly unstable DNN install to a stable one in a matter of a couple of days - identifying and either fixing or documenting what needed to be done to get them running and meeting their goals.  We unraveled the hosting issues, and the stability issues, got them up and running and all prepared for future growth.  Perfect right?

A quote from the customer: "WOW!  We love your process.  You keep us informed, and almost seem to have a second sense for exactly what we need.  You let us know before accruing hours that something might go over an estimate, and you work with us - and our other vendor partners - in a kind and courteous way as you have done this - paying attention to our priorities.  You've done more in the last 48 hours for our site than has been done in 2 years of development."

Awesome.  Our customers say the best things about us and we love them for it - and when we get a compliment like that it lets us shine up our white armor and say - see we CAN ride that horse!  But the customer didn't stop there.

"I'm sorry to inform you however that the board has decided to move from the DNN and MS SQL to a php and mysql platform, because of all the frustrations we've had with DNN.  We just want to stabilize the current install while we develop a replacement in another languague." 

WHAT!? Hold the horses.  The problem isn't the platform - it's the programming teams.  It's not whether the platform can do what you want - it's whether the team you had used the platform to it's best advantage, using pre-programmed tools when appropriate and developing custom modules where they are needed.  It's whether the team understands your requirements, budgets and goals, and works with you to make all 3 fit into the same project iteration.  It's whether the team building your software knows the ins and outs of the platform to really take full advantage of it.  And it's whether you trust the people building stuff.  It won't matter if you move to a new development platform if your developers don't know, understand and live these precepts.

I haven't closed the loop on this yet - I'm still hoping to convince this client (through references from  other clients) that it's the team not the technology.  Wish me luck!

So for all of you out there right now cursing your platform (whatever it is) just be sure that the problem is really technical not cultural. 

If we treated everything in life like consultants and developers are treated

Give this excellent video a watch:



... then ask yourself - is this the way I treat my vendors and development partners? Is there a lesson to be learned here? If we go into a grocery store to buy something we don't dicker over the price, try to delay payment or anything else. We go, we buy an item, we pay for it and we leave. Why then do people feel compelled to dicker over the prices offered by resellers of professional services like software development, or computer tech support? What is different about the product they offer from the product the other service professionals in this video offer?

My guess is - they really aren't that much different. We don't ask our hairdresser to "wait 30 days" till we can pay them. We don't try to talk our waiter or waitress down in price so we can get our meal cheaper. We just decide - is their product or service worth the price I'm paying and then we either do - or do not - do business with them.

In a great software development effort, both parties are working to maximize return on investment and minimize cost of development. This is what long term relationships are built on. Not a "sell it to you once and then soak you for everything you've got" attitude, but a sell it to you once and work together so that the product continually improves until it's delivered, and continues to improve after that.

So the next time you feel tempted to "dicker over price" think about it. Is the product or service worth it to you? If it is you might want to consider just paying that amount then. Your vendor with thank you for it and you'll be developing a long-term partner relationship that may last forever!

Usability testing in entrepreneurial software

Jeremy Liew of Lightspeed Venture Partners has an excellent blog post on Usability Testing and how it applies to building entrepreneurial software. In his post he mentions that it's not just about rapid prototyping and turnaround (which he approves of) but also says that at some point you have to step back and do surveys, and psychological profiles of users and see exactly HOW they used the site. This is a critical step in building software, and obviously (since Jeremy commented on it) important to getting venture funding as well.

At OS-Cubed, we believe that usability testing should be scoped into the project itself, and the amount invested in it should be scaled according to the entrepreneur's budget, but it should be conducted throughout the development process as you're building your demo or proof of concept and rolling out your RAD prototype. In the early stages usability testing does not need to be either expensive or costly. You can do much of the testing yourself with the demo as it's rolled out. Noah Kagan of Mint lays out the steps for you in his excellent post. They involve basically: determining what to test, finding a representative user base, and then testing by observing. Noah recommends using Webex products, so far we've been lucky enough to have user bases that are representative right here in Rochester.

As Noah points out - doing this can be frustrating for the observer. The observer needs to sit back and let the user do it - without intervening or showing them how.

In our experience most of the user testing we've done with KaJour our product for Knowledge Athletes has shown up issues in the scalability section - which you'd expect in demo software. We'd actually anticipated these issues but didn't have the budget to build production level. We consciously chose with the entrepreneur to build more features, rather than make the features we had more robust. The users have also come up with unique and interesting ways of using the product that we didn't anticipate and neither did the Knowledge Athletes staff. Through our user testing we've found new markets, new ways of thinking about what we're doing and developed new teaching paradigms for the community we're serving (at the moment mostly high school and college students with this product).

Although Jeremy points out the obvious benefits of using usability testing to be sure your software is stable and simple to use, he doesn't mention that really listening to your users can allow you to create new and better uses for your software, and take your product in an entirely new direction. To do that you need to truly listen to your users and find out what it is they need - what pain you are solving - and how you could do it better.

What is the typical funding cycle of a startup software entrepreneur?

More often than not when I get a question from a budding software entrepreneur the question is about funding: How to get it? What are the next steps? How can I be sure I'm getting the best dollar for my investment?

At OS-Cubed we only work with companies that have at least some funding. Not necessarily angel or venture funding - but FFA (Friends, Family or Acquaintences), self funded bootstraps, SBIR or STTR grant funded, or some other sort of funding mechanism. In today's Web 2.0 world, most of the "big funders" - the angels or ventures of the world - expect that you will have some "skin in the game" and already spent some dollars or sweat equity building the demo or proof of concept of your site.

Web entrepreneur and funding expert Brad Feld says that a typical Venture or Angel firm might see 2000 applications for funding in a year, and 15-25% of those will be for software development projects. If we take the 20% median that means 400 of those applications are for software projects. He also said that of those 400, 1/2 of them had already spent between $25,000 and $1M on building a demo or proof of concept for their site - before they applied for funding! That's 200 demos or proofs of concept per year - all funded by FFA, Grant or bootstrap dollars - and that's just for one firm.

So how does that funding actually work? We've worked with a number of entrepreneurs and here are a few models that can be successful:

• Grant funding - public or private grants from interested parties that can assist you in startup. The most obvious of these is SBIR, but there are others.
• Bootstrap funding - create a small app using FFA/Self funding, convince people to use it, use the revenue from the small app to pour back into the app itself, convince more people to invest, and build it bigger and bigger until you have a provable model that you can get funded for.
• Sweat equity - give yourself and/or others a portion of your equity to build the first versions for free. Use that result to apply for other funding sources.

Each of these has it's upsides and downsides. We'll address each one in a future post.

How important is a proof of concept?

So just how important IS a working proof of concept to funders? Can't you just drop your idea on an investor and sell them on it - then get funding to build it? Well yes, you can -if you have a history of building software companies before and succeeding, or more rarely if you have an idea that's just so mind boggling that the Angels and Ventures just jump all over it. Pretty rare though. Most serial entrepreneurs (whether they have a solid record of success or even a spotty one) have a leg up on the rest of us when it comes to getting funding for an idea before they build it.

But let's face it - those folks already ran the funding gauntlet and convinced someone to lay down cash for them. For the folks that have a great idea but have never implemented before they have to "prove their creds". They have to show the potential funder that they have the ability to deliver on the promise.

One of the best ways to do this is to bootstrap a demo or proof-of-concept so that you can show your potential funders real numbers and testimonials, with real people using your software. A great demo will show investors that it's a cool idea that can generate revenue. The characteristics that make a great demo are as follows (and I'm always open to ideas about what else may make a great demo):

• You must limit the scope of the demo to what you can afford. Many entrepreneurs try to jam as many features as they can into their demos - and none of the features end up working well because they really need the $$ the Angel or Venture will invest to build production level, fully featured software. In this case KISS is fine (Keep it Simple Silly).


• You want to build something that has limited scalability (might service only a small audience), but that still shows the core feature(s) of your product and how it delivers revenue. You may end up tossing out vast quantities of what you develop when you move to building production software. THAT'S OK. What you're building in this round is enough of a system to convince an investor to give you the $$ you need to make the REAL software.


• It's extremely difficult to create fully scalable business software on an FFA funding (Friends, Family and Acquaintances) budget. Building scalable software is not easy, or cheap. It takes a lot of resources, good management and a solid team to build, support and improve software that is scalable and stable. I love when people point me at a site that has had millions of dollars invested in it and say "I want to build something just like that only better" and I have $10,000 to do it. It's just not going to happen. Build something realistic.


• Yes delivering revenue is important - even if that revenue is small. If you're building something based on an advertising click through model - having users click through in your demo is as important as whatever cool features you've designed to get them there in the first place. If you can show your funders that you have the ability to deliver not only on the the cool feature but on the revenue generation you'll be that much further along towards proving your model. You don't have to generate revenue but you must prove you COULD generate revenue and show how you will do so.


• Although you want the demo to be as stable as possible, it's OK for it to have a wart here or there, or an unimplemented feature. You can still build a demo that proves your concept without spending the money to make it fully stable and scalable. Limit your target audience to one browser, a limited number of users, single language, one checkout system, etc. Be sure the functions within those limitations work well, and be clear about them if presenting. Don't promise Firefox compatibility if you haven't tested it and don't be shy about saying "At this time the demo only supports [Browser X], but once we're funded we'll expand support to browsers y and z."


• Take the feedback of your beta testers seriously. If they never use a function that you spent a lot of time developing - consider throwing it out. It's never good to clutter up an app with features that users don't want or need. You don't have to run out and fix or change things in this round, but preserve all those comments and criticisms and be prepared to address them in future rounds or plans.


• Don't forget about monetization. To ultimately succeed in the venture world you need a business model that supports 5x growth in initial investment. If your initial tests don't prove that out - you might be in the wrong business. Better to find that out now.


• Build incrementally, and do it within the scope of the funding you definitely have - not the funding you hope to get. Release early and often.

Initial proof-of-concept and demo software is frequently created with FFA (Friends, Family and Acquaintance) or grant money. As such, it's typically limited in quantity, may be only available on a cycle or with a specific deliverable, and - especially with the FFA money - it can be painful to say you spent it on development and then never moved on to the next step where they might get their investment back. It's incumbent upon an entrepreneur to spend that money as productively as possible to ensure success.