Can non-geek startups get suitable software solutions?

When you think of a startup company, you often think of young girls and guys who are serious computer geeks that can create a software solution around which to build a great new business

They’re often CMU and Standford grads…people who can create their own, unique web applications, desktop application, mobile apps, etc. Those applications can do all kinds of fun and crazy-cool things. They look awesome and make for a promising and valuable business.

But this idea that only the computer geeks can create a startup is a myth. There are plenty of young people, and not so young people, who have great ideas to start a new business, but aren’t geeks. These people have fantastic ideas, know what needs to be created, but aren’t able to do it themselves.

That’s fine, that’s not a problem. The technical or software solutions can still be created. The question is how. Once you start thinking about the how, a bunch of other questions come up, such as what features, who will do it, how will it be paid for, etc.

I’ll be writing a series of posts on this topic to flesh out the ideas on how startups can get their own technical solutions to startup their business.

The series will follow this approximate trajectory (which may change mid-flight):

  1. What are the technical solutions startups often need
  2. Who can create those solutions
  3. What should be created, and shouldn’t be created
  4. How to get it done
  5. Where will the money come from

Hopefully this short series will be useful.

4 Reasons Why MVP’s are a good idea for a startup

Are MVPs (i.e., creating Minimally Viable Products) a good idea for startup companies? Or for existing companies that want to create a new product or service?

Yes, absolutely! Why? I want to answer this “Why” question in this post. This idea is important and appropriate before I get into the short series of posts I mentioned in a previous post: Can non-geek startups get suitable software solutions.

First, what is an MVP? MVP = Minimally Viable Product

An MVP is the idea that you can create and release or sell a very, very small product with very few required features. This small product makes it faster and easier to get the product into the market, and to get proof of whether the concept in the product actually works or not…i.e., are customers willing to pay for it or not.

This idea applies not only to creating a new product from scratch, but also applies to adding new features to an existing product, as well as companies that provide services as opposed to products.

Now the question is, why should you do this? I see 3 reasons why:

  1. Cheaper – It takes less money, as well as effort and mental energy, to create a much smaller product
  2. Quicker – It takes less time to create the much smaller product.
  3. Last Risk – You risk less money, which then puts less money
Given those 3 reasons why, you can then realize additional benefits from executing an MVP:
  1. Faster to market – You can create the product and get it into customers hands sooner. This is often important when customers tastes and preferences change very quickly these days, and your competition is often reacting much quicker to your same customers changing preferences.
  2. Make money sooner – You are able to start earning money soon because of the two benefits above.
  3. Quick proof of the concept – You are able to learn if you’re product is any where close to hitting the mark as a result of the “Faster to market” and “Make money sooner” ideas above. The idea is that if you make any money at all, you can then figure out that you might actually have something good.

To execute an MVP is much, much easier and cheaper than creating a full blown product that has so many features that you “think” are necessary for the first version. But keep in mind the problem with creating an MVP is the tough decisions you have to make to strip away the fluff and figure out what really is minimally viable and a must-have to release the product.

We apply this idea to many projects in custom software solutions we create for our customers. Those projects are often situations where the customer wants to start a new line of business in an existing, well established company. Additionally, they are also often new companies or individuals starting a new company that wants to create a new product or service.

The solutions we create end up being small custom desktop applications or a new custom web application. Often enough, we end up continuing to modify and extend the solution over time, or the customer grows sufficiently that they can take over maintenance and improvement of the product in-house.

Who can create the technical solutions for a startup?

In continuing the series of posts on software solutions for startups started on Nov 20, here I’ll list who would create those solutions.

As a quick summary of what we’ve discussed so far:

  • Startups often don’t have the internal capabilities to create their software applications unique and critical to the startup’s success
  • Those software solutions are often web applications, mobile apps, and desktop applications

Now the question becomes, if the startup can’t create the technical solution themselves, who will do it for them?

Here’s a short list of options. Further below is a short discussion of each.

  • Your brother-in-law’s nephew’s cousin’s neighbor kid who is in highschool and knows something about computers.
  • College computer science major
  • Freelancer or independent contractor
  • Technical employees (programmers, software developers)
  • Custom software shop (large or small)

First of, if some suggests to you that their brother-in-law’s etc etc can help you, run away screaming. Don’t even talk to that person. Or if you don’t want to run away, just smile and don’t say anything. Don’t ever even consider going that route. The kid likely knows a little something but couldn’t write much beyond a simple Hello World app to save his life. Even if he is really good, he has no time…soccer practice, school, homework, XBox games to play…it’ll never get done even if he’s cheaper than dirt.

College comp sci majors? They’ll be much better at creating an application, an a little bit more expensive than dirt. But they’re also really really busy and the application will never get done. They’ll work hot and heavy for 1-2 weeks once you give them some beer money. But you’d be hard pressed to get any end results anywhere close to the schedule promised or needed.

So far, am I being harsh? Yes. But what I’m staying isn’t too far away from the truth. I’ve heard stories from customers that have tried these routes to get solutions done. We have also had to cleanup after sad situations like this. And when I say “cleanup” I really mean “throw it all away and start over”.

When we start talking about employees that are programmers, software developers, now we’re getting close. If you have these people now, or you are funded well enough to hire them your chances of success increase somewhat. But a lot of the responsibility for a good solution still relies on you. You need to know how to hire the best of the best of the best. You need to know how to manage the project to success, or hire someone that will. If you haven’t done this before, please tread carefully. Believe me, hiring developers, project managers, testers, etc is a special skill that only comes with experience and learning…which itself comes from making mistakes (I’m speaking from experience here).

The last group is software companies that create custom software solutions, which are are one. I honestly think they are the best solution out of the options above if you don’t have experience hiring technical people and managing the project. If you can find the right company, they’ll have experience working with startups, they’ll understand how to create solutions for startups. This means that they know how to create solutions incrementally and prove the minimal versions in the marketplace. This approach makes the project initially cheaper, faster to market, and significantly lowers the risk.

Given what I’ve summarized above, it would make sense to go with the smaller custom software shops.

Am I biased on that answer? Hell ya! I think we do a great job executing software projects, including those projects we do for startups. But given that, we’re not always the cheapest solution. Freelancers can be cheaper, but then again, one’s experience and capabilities with hiring and managing a complex software project will impact the potential for the starup’s success.

After you figure out who can create the solution the next question is often how will they pay for the solutions…that’s another topic for another time.

Next is what should be created and what shouldn’t be created. That’s always a really interesting question. The answer has a HUGE impact on the success of the startup.

What is The True Cost of a Customized Software Solution?

Customized software is a popular choice for many businesses because of its ability to be 100% customizable to your business’ processes and operations. But, the biggest hesitation for companies is the myth of the high cost associated with custom software.

This isn’t always true. The bottom line: custom software solutions do not always cost more than packaged, off-the-shelf, shrink-wrapped solutions. Inevitably, off-the-shelf solutions require a lot of adjustments to be a valuable resource for the company. That can be very costly. In fact, those solutions can turn out to cost more than a custom software package.

One concern of companies who decide on a custom software solution is the maintenance costs.

What do software maintenance costs cover? Why do they exist?

  • To prevent bugs that could interrupt service
  • To improve performance to make tasks faster and more efficient
  • To upgrade features to meet future processes, operations standards, etc. Remember that as your business’ processes improve (as they should), so should your software.
  • To perform data-back up and disaster recovery To cover hosting costs

What is the estimated amount for maintenance costs?

Maintenance costs for customized software usually run a reasonable 15-25% of the project cost. Don’t forget that maintenance fees must also be paid for package software, though it is often worded differently. For off-the-shelf solutions, you will pay for an upgraded version, new licenses, and anytime that you need support.

Custom software is the ideal solution when you have very specific needs for software to fit unique aspects of your business, like a process for selling and tracking those sales which is better than existing off-the-shelf application.

Additionally, keep in mind that when the software project has been well-defined, managed well during the development life cycle and well-tested, you will have minimal maintenance costs.

Lastly, when the project is completed by a professional, knowledgeable company, where the project is on-time, on-budget, and on-spec, the whole solution can provide a very significant ROI, often far in excess of the maintenance costs.

The Custom Software Question: To Build or To Buy?

If you’re like most businesses, you use software on a daily basis for critical functions: managing projects, sending invoices or tracking inventory. The plan for most businesses is to buy a mass market, shrink-wrapped off the shelf (OTS) application, like Quickbooks or NetSuite. And that is a huge mistake. Often OTS solutions only meet 30% of your business’ needs. When the functions are vital to your business and deal with core processes, it is important to use a solution that you are in control of. As software is essential for your business, consider the distinct advantages that custom software has over an OTS solution: Custom software is:

  • A customized glove fit for your business’ specific needs: Before the building begins, the software company sits down with you to understand your processes and then develops the software specifically to your day-to-day functions. In OTS solutions, it is the other way around: you are forced to conform your processes to the software. With a custom solution, you monitor and control the entire process.
  • A solution that comes with local, personalized support: Do you currently have 1 or 2 technical software staff members that support your custom software solution? If one of those team members were to leave, how would your current custom software system be maintained? You’re currently completely dependent on their knowledge of your system. When working with a professional, reputable software company, you have access to an entire team of developers who understand your system and are ready to help.
  • A lower cost than other options: You may be under the impression that custom software is costly. However, on a per-user basis, or when calculating the ROI of the custom software, it turns out to be much more cost-effective than limited OTS solutions. Additionally, once you have hired a company to develop the software for you, you reduce the need to pay for costly individual licensing.

The bottom line? It’s better for your business to create a custom software application, rather than continue to have frustrations, high costs and limitations with your current system.

What technical solutions do startups need?

In a post on November 20 I suggested that there are many startup companies out there that aren’t able to create the technical parts of their new product or service on their own. This is in opposition to the many startups started by technology experts or geeks that can create their own solutions for their startup.

I was referring mostly to startups that need a web application, and mobile app, or some other software or hardware technology solution that is integral to their new product or service offering.

This post will be the first of the series of short posts about startups creating their new product or service with technology involved.

The first task is to briefly define what kind of technical solutions we’re referring to. That’s pretty easy. They can be summarized as follows:

  • Web application
  • Mobile app
  • Desktop application
  • Physical devices

Most often the technical solution startups need or at least think they need is a custom web application or more often a custom mobile application. This application would be the tool with which their customers interface with the startup, consume content, interact with data, and possibly make payments as customers.

These web and mobile solutions can be created as HTML5/CSS3 web applications with Responsive design to provide one solution for both platforms. Sometimes creating the mobile apps as actual applications for each platform (iOS, Android, Windows, Blackberry, etc) are necessary. The choice depends on a number of factors, the discussion of which is worth multiple blog posts…so I can’t get into that here.

There are some startups that would need to have a custom desktop application created. These are often applications with more complex functionality than can be executed on the web, or where the target audience requires or expects the solution to be provided as a desktop computer application.

Lastly, there are startups that not only need some of those solutions, but also need to have physical devices created for their solution. I’ll skip discussing physical devices since that’s not our area of expertise.

We’re in Pittsburgh. Pittsburgh is making a come back in many ways including the economy, a technology education and solutions hub, and a healthy startup community. At Ectobox we have been getting more and more requests from startups of various types to discuss potential solutions to create. It’s almost one startup a week that we talk with about what can be done. It’s definitely an exciting time in Pittsburgh and a great time to be in our line of business.

In the next post I’ll discuss who can create the technical solutions that startups create. There are a lot of options to consider. Til then…

Three Reasons Why Customers Like Great Customer Service

I have found that one of a few big reasons that customers stick with us is our great customer service. I have discovered this through conversations and through surveying customers with Survey Monkey, that they really like and really want great customer service.

For our custom software business that means providing them with:

  1. Quick responses
  2. Solid technical work
  3. Honest feedback

Quick Responses

Provide customers with quick responses so they know a human being is on the case. An autoreply from your case/ticket/bug management system is fine. But be sure to follow-up quickly by a human being. “Quickly” could be in a few minutes or at least in a couple hours. You don’t necessarily need to solve the problem that quickly. Just let them know a human is aware of the issue.

Then you should define the priority of the work, and thereby, the ETA for the modification or fix. (We work on custom software applications so we always thing in terms of new features, modifications, and bugs).

Having company rules or policies which your customers agree to can make this whole process a lot easier and clearer.

Solid Technical Work

Great customer service isn’t great without quality resolutions. If you responded to the customer quickly that you’re on the case, but then deliver a buggy fix that the customer immediately discovers, then their opinion of you just went down a notch.

When you work on the feature, modification, or bug to a close, make sure you’ve done it right. Don’t rush it. Rushing to a fix does no one any good because the quality ALWAYS seriously suffers. No shortcuts. No silver bullets. Take a bit of time to think about how to solve the problem the right way, the do it.

Honest Feedback

Honestly is indeed the best policy. If your customer requested something that you’re not sure about, ask questions to confirm. If they asked for some custom software modification that doesn’t make sense relative to other features they have in the application, mention it. If they didn’t request a small aspect of a feature that you think might be a good idea based on how they normally work, suggest it.

My customers have always appreciated this kind of feedback. We’ve been able to improve upon their requested features, and avoid potential problems.

So, if you’re running a custom software business, or any type of business that provides customer service, make great customer service one of the major pillars of your business, and you’ll do well for yourself.

What methods are used to estimate custom software?

There are two primary methods to estimate and propose custom software projects that we hear about. Those methods are:

  • Fixed cost – The development team may attempt to estimate the time and costs related to creating a software application. The estimates are normally generated using a requirements specification document, which defines what to create in the software application. They may also add some type of fudge factor to the estimate to give them more time in the estimate to complete the project within the estimate. If the time and costs go over the estimates, then the developers cannot charge the customer more than was proposed with the fixed cost estimate.
  • Time and Materials – There may be an attempt to estimate the time and costs of the software project. There may be a written requirements document to use for the estimating. Most often though, the developers will work until the application is complete, and then bill the customer for the time and costs spent.

The Fixed Cost method of estimating and proposing a project can be a good method to use, only if the estimate is relatively accurate, and doesn’t have an excessive fudge factor. If the estimate isn’t accurate then there can be serious trouble in the project. What often happens is that the developers go over their costs and time in the project, and realize they can’t charge more for the project than their additional work, or the customer won’t let them charge more for the project because it was defined as Fixed Cost. Sometimes quality and schedule in the project will suffer significantly. The developers don’t want to continue working on the project essentially for free. But the customer wants the project done. Then the developers will continue work, but the project will become a much lower priority project, because they want to work on paying projects to keep the doors open.

All-in-all it can turn out to be a very tough situation.

Some software development companies can make fixed cost projects work, but there are many more that can’t.

Time and Materials projects are also tough. They can sometimes not work out well because there is little to no clear definition of what software will be created, how it will work, when it will be done, and how much it will cost. The project’s features, cost, and schedule can creep continuously until the customer gets frustrated, cancels the project, and reluctantly pays the costs for time spent on the project.

We have found that what works best is a slight modification of the fixed cost project. That works when:

  • The project plan and software’s requirements are very well defined
  • There are clauses in the project’s contract that requires the customer to pay for changes to the applications features if they requests changes that aren’t in the original requirements specification documents, and
  • When the developers working on the project are experienced and and successful at accurately estimating projects.

We use this last method. We make sure the requirements are well defined, no matter what type of project it is. Our contracts always have the clause which states that if the customer changes the requirements it is a Change Order, and our developers are very good at estimating projects.

Rewrite or not?

We face this question, “Rewrite or not?” with customers every year.

“We have a custom software application written by [ABC company or programmer] in [XYZ technology]. It works but it has problems. Should we keep it alive and continue modifying it? Or should we start from scratch again and rewrite it?”

That is a very good question. This question of keep alive or rewrite the software has been addressed by others in our software industry. This specific article references the recent rewrite from scratch of the well known project management tool Basecamp by 37Signals, and a timeless article by Joel Spolsky on the same topic but with the opposite view.

The summary of the two opposing points of view are:

  • Rewriting is good because the old product was well done but was written for a different time, with a different frame of mind, and with old technology. Everyone will be better off with better application.
  • Rewriting is bad because “You are wasting an outlandish amount of money writing code that already exists”…the loads of code debt or bad code can be fixed, a rewrite isn’t necessary.

These are both solid, well supported lines of argument. But I think they are addressing different situations. Jason Fried of 37Signals doesn’t talk about Basecamp being a bad application with bad code, just that it was great, but can be better. And let’s face it, if you follow the software company 37Signals you know they’re not hurting for money and can afford to do a complete rewrite.

Joel Spolsky addresses the other type of software application, the ones with problems, bad code, slow performance, etc for the large, widely distributed applications. He says all of those things can be fixed and the cost to the fixing is much, much lower than the rewrite. He’s write…err, I mean, he’s right.

What I like is the clarification by the blog post author, Garry Robinson, that the software application should be rewritten if either the database design really poor, or the code is really poor because the developer(s) didn’t know what he/she was doing, or both.

Garry is essentially saying it’s a matter of severity; if it’s really bad, rewrite. I agree. Issues can be fixed if the problems aren’t endemic throughout the code and database. But if they are, rewrite.

In fact we are facing that exact situation with a customer’s application. An application was built by an internal person years ago with Microsft Access and SQL Server. On their own those are fine tools to use for this situation, and a great custom software application can be written with them. But the way it was written was…well, it was not good (an understatement). The application is really hard to support, especially in some specific feature areas.

We are now working with the customer to do a complete rewrite. It will give them a solid application that won’t have the frequent issues it had before. The customer will also get new features and capabilities they couldn’t dream of with the old application.

When to estimate a software project’s cost?

Here are several questions and answers regarding estimating custom software application projects with companies. This topic is something I have spent a lot of time thinking about over the past years. Keep in mind, the idea here is to start the conversation early about a software project.

Q: When should a software developer or company estimate the cost of the software?

A: As early as possible. Doing so sets expectations and allows the sales process to go forward with the company. And if the numbers are too high, that will be an early indication the company can’t afford a custom software solution. It allows both the developer and the company to move on, or to steer the conversation to a lower alternative solution.

Q: Will the estimates be accurate?

A: No, definitely not. They won’t be accurate until the developer can spend more digging into the project later on in the sales and discovery process, or the early stages of the custom software project.

Q: What happens if the developer under estimated at the beginning of the sales process and the final estimate in the proposal is higher?

A: The developer should be up front and tell the company they didn’t have a chance to dig into the project deeply until now, and this is the actual cost of the project. Hopefully the developer has business processes in place to prevent this from happening, of course.

Q: Can the developer avoid underestimating?

A: Yes, by going really high with their ballpark estimates…but reasonably high…or by doing an early discovery phase to define the problems to be solved with software, and confirm whether a custom software application is the right fit as the solution.


Typically in the initial conversations with a company the company will tell the developer generally what they want in a custom software solution (very high level, no details), and then ask, “So, how much is that going to cost?”

The developer obviously can’t give them an exact cost for a custom software project, right after the developer just heard the high level ideas about the project, and don’t know anything about the details. But if the developer has some experience in the area of custom software development he/she/they can at least take an educated guess.

But, be careful of the educated guess. The developer shouldn’t indicate, nor should the company assume that is definitely the final and total cost. The developer should make it absolutely clear that the educated guess in just that, a guess, that they haven’t had the chance to review the project in detail, etc. The developer has to be honest with with the prospective customer that they are willing to discuss numbers early, but everyone at the table needs to understand the numbers are very preliminary and will very possibly change up or down.

Being honest and upfront like this with a prospective customer can go a long way in establishing a good, trusting bond with them. If they see the developer isn’t afraid to discuss numbers, and they understand that they are very preliminary numbers, then there the conversation can be more open about whether the developer is a good potential fit for the company and the project.

This prevents everyone from spending otherwise wasted time trying to build a business relationship that, had anyone been paying attention to the signs, would have known it wouldn’t have worked out.