From First Phone Call to Business Transforming Results

Understanding the Custom Development Process

If you’ve never done custom software development, or not done it with developers who communicate well, then the process can be a bit mysterious. Maybe it’s also mysterious to you how your mechanic fixes your car (it is to us) — but that doesn’t generally matter as fixing your car is done without your help. Custom software development, by contrast, needs your intimate involvement as the best system is the one matched exactly to your business’s needs and goals.

From the outside, custom software development looks like this:

So what’s in the blue "custom software development" box above? Let’s take a look.

Initial Consultation / See if a Project Makes Sense

Before we start any development work, we first determine if a project makes sense. For new clients, that starts with a free initial consultation call by phone or Skype usually lasting between 30 and 90 minutes. Our first questions are along the lines of "What would you like to build?", "What’s your organization like?" and "What are you trying to achieve?" A new customer’s top question is usually "What would my proposed system cost?" After a first call we seek to have at least rough answers to all of those questions.

In this stage, sometimes feasibility is easy to calculate. If we’re asked "Can you build a functional clone of Facebook on a budget of 200k?" The answer for that is "no." (We’ve been asked!) Or sometimes we’re asked "Can you create a system that will fully automate all of the office tasks for my one person business?" to which the answer is "Yes, we could automate all of that, but the amount it will cost vs. the amount of time it will save doesn’t make sense. It would take more than 10 years for that investment to pay off. You’re better off saving the money, hiring a part time admin person, and then calling us again when you have 5 or 10 people instead of one." But if we hear "We’re a small, rapidly growing organization, and we’re getting buried under the new work because our tools are so inefficient," then that’s a much more promising situation, as automation will reduce the rate of growth of staff costs while unleashing time for the staff to accelerate growth.

In an initial consultation we also check with a client to make sure custom software is a good fit for them. Have they tried available off-the-shelf alternatives? Why not use one of them? If the answer is that the client should use an off-the-shelf solution, they go away happy and we have good will toward us in the future. If the answer is that the client shouldn’t use an off-the-shelf solution then the reasons they explain why not help us zero in on what they’re trying to achieve and what they need.

We also share ideas on achieving a client’s goals. Recently a potential client contacted us to explore software for a new startup, but their budget wasn’t up to what they were wanting to do. We came up with a way to do it for half of what other firms were quoting by coming up with a better approach, but that still wasn’t in this group’s budget. But that didn’t matter, as in our judgement this particular client needed to focus first on building an audience for their ideas, not yet focus on building software. So we suggested starting with online blogging and content creation around their idea, building an audience, and connecting with future customers, and validating first that there is both interest in their idea and people willing to pay for it. (The particular idea was a good fit for this approach.) So in this case we actually ended up telling the potential customer "You don’t need custom software, you need to start writing and engaging an audience in the ideas around your startup." If they can draw an audience, they can get to making software for it. If they can’t draw an audience, software development would be wasted money.

1. Determine What To Build

The hardest single part of building a software system is deciding precisely what to build. It’s also the most important. There is no cost savings greater for a system feature than the cost forgone by not building something you don’t need, and no greater business advantage gained than the ability to do things competitors simply can’t do.

Steve Ballmer, CEO of Microsoft after Bill Gates, laughed at the iPhone when it came out. Not only could Microsoft’s leadership not think of building something as game changing as the iPhone, even when shown one already built, they still didn’t get it. Microsoft’s failure wasn’t that their engineers couldn’t build an iPhone if given the designs (they could have!) Their failure was in not even being able to think of creating such a device to begin with.

In the "Determine what to build" stage (parts of which are also sometimes called "project discovery", "system specification and design", or "specification and architectural development") we uncover what your organization wants to achieve, and then partner with you to come up with a design for a system to achieve it. One of the first questions we ask new clients is "What would you like to build?" But that’s not actually what we need to know. We need to know "What would you like to achieve?" and there’s a strong distinction.

Our clients tend to be innovators. After all, they are hiring developers to create new solutions, rather than muddling through doing things the old way. Therefore, clients often have a business problem, let's call it "A", and then they think to themselves "How can I solve 'A'?" They then think up a solution to A — let's call it 'B'. Then they call us and say "Can you build us 'B'?" To which we invariably respond, "Well, yes, we could — but that's probably not what you want. Let's talk about 'A'." We say this because, given a business problem, Mighty Ant DataWorks is one of the best in the world at coming up with a technology solution. We ask "What would you like us to build?" just to shed light on what you want to achieve, and then we delve deeper. We then create systems that solve problems better than our clients ever could have imagined.

For example, the founder of FamilyInfoShare, a startup centered on capturing a great variety of financial and other information for people to share with their family members, estate planners, and others, contacted us about creating a software system that would use a friendly, comprehensive online interview to gather information (sort of like the product TurboTax does to interview you to help you prepare your taxes.) We gave this founder a ballpark estimate on costs in his initial free consultation call, but as we had a 3 month wait at the time before we could start on new projects, he explored working with another team instead. The other team gave him a very similar cost estimate as we had, and worked out that they couldn’t build the full product on his budget, but could get him started by building the first 20 screens of the interview which could then be expanded later. Things ran a bit long on getting started on his project, and he checked back with us when we were available, and ended up going with us to determine what to build. We decided that what he needed wasn’t interview screens for his extensive interview process, what he needed was a software system to let him build his own friendly and easy to use financial interviews. We built him a system to build his interviews, and he ended up building over 300 screens of the system for the same price another group quoted him to build 20. We brought two big advantages to the project over the competing group: we uncovered what he actually needed to do to accomplish his goals, and we had (the somewhat rare) developers who were experienced in building such systems.

Software specification and requirements gathering consists of working with your staff to see what they need to do (not necessarily what they are currently doing), and determining how a new system can let your staff do it much better. We interview users, review existing reports, learn existing systems and procedures, uncover why things are done the way they are now, then, with business goals, budget, and other constraints defined by the client, come up with new solutions to old problems to get work done much more quickly, with fewer errors, and less effort.

The specification work product for a simple job might be a couple of pages of written description exactly outlining the business problem to be solved, and the requirements for the solution that will be provided. A specification for a larger job might be 80 pages of features and system details, spelling out the various trade-offs, including diagrams, sample files, mock-ups, and more.

Design problems, missing features, and system flaws are 50 to 100 times cheaper to fix at the specification phase of the project (where you are exactly describing the future system, not yet constructing it) for the same reason that it's easy to erase and move the position of doors on a building blueprint than to later move the actual doors on a 12 story building. We figure out what we will build before we build it, more so than other developers — both because we can (as we have the required discipline, communication skills, and a mature development methodology), and also because it saves our clients a great deal of time and a great deal of money.

2. System Construction

Most of a software project’s budget and most of its time are spent on actual system construction — the task of actually building the software. During this phase you receive regular updates and view visible system milestones as the system is completed. When new questions come up during system construction your development lead will get your input so the system can be matched to your business needs.

As mentioned earlier, the cycle of invention is repeated several times during most projects. We repeatedly go through the cycle 1. determine what to build → 2. system construction → 3. testing → 4. deploy to users → 1. back to determine what to build. Each time through the cycle, new functionality is deployed to users, the business gains the value of its investment, we learn better what to add to the next development cycle, and the process repeats. So the initial plan put together in the very first "Determine What to Build" cycle is a high level plan, mapping out the relative size of the various development cycles of design, build, test, deploy, then picking which task to do first. Before starting system construction we figure out what your business needs to achieve in the big picture, then determine which modules / smaller development cycles will get us where we want to go, then specify the plans for just the first build, test, deploy cycle in great detail (leaving the other cycles in broad outline.) We then execute, build the new first module or set of functionality for the system, get users using it, and then everyone will have even more ideas on what and how to do the next development cycle after they have learned from the first one.

For example, with our client ForensisGroup we built (and are still adding onto and maintaining) a business automation system that radically increases what their entire company can do. When we first started work with ForensisGroup they had an internally built database system that they had been using for over 15 years. It did relatively few things, had a very cluttered interface with all sorts of odd features (many no longer used), was unintuitive, and inefficient. But it was also what the entire company had solely used for 15 years! Everybody was used to it. Everybody thought in terms of how the old system did things — with procedures based on limitations it brought. Henry Ford said "If I asked people what they wanted, they would have said 'faster horses.'" If we asked ForensisGroup what they wanted, they would have said "To do what this system does but much better."

Working with ForensisGroup we mapped out what they wanted to achieve, where they wanted to be long term, what tasks would be the biggest pay-off to automate first, and then picked our first module/project: replacing their old database system. So we examined everything that the old system did, made sure the new system would replace that functionality (with vastly more capabilities), and then also added in all sorts of standard workgroup automation features that come with any of our typical systems (client activity tracking, automatic mass email systems, automatic email template systems to generate emails from a database and automatically merge in customer information, reporting, query, export, and other tools, etc.) We designed this system, built it, tested it out with them, then deployed it to their users. The users saw truly dramatic improvements in capabilities and efficiencies. They also had to learn how to do things in new ways. Some of what ForensisGroup staff used to do every day were things that were the core mission of the company — talking with customers to match them up with great legal experts, working with experts that ForensisGroup matches on necessary client issues and details. But many other tasks the company’s teams did were just repetitive work required because of limitations of the old system. The teams learned new procedures and tools to do their jobs in new ways, and productivity — and ideas for future improvement — both continued to increase.

After we replaced ForensisGroup’s original old system, and the team was fully up to speed on using it, and excited about adding additional improvements, we next automated dozens of their operations reports. These reports were previously painstakingly compiled by hand each month and also at the end of each year. We looked at all of these complex reports, designed a system to automate them, and when the operations reports project was done all the work of compiling those reports disappeared forever. They could now run any report, at any time. They started using the reports more often as they were so much easier to run. They now had automatic reporting showing operations numbers, automatic pie charts, and automatic line charts with interactive date ranges — something they hadn’t even imagined when creating the reports manually.

After the operations reports project, we helped ForensisGroup with a project to help their company website (which hadn’t been created by Mighty Ant.) We managed to triple the speed of their website by instituting a proper caching architecture dropping page lead times from over 6 seconds to under 2 seconds. We also pointed them toward a variety of other necessary improvements (and encouraged them to seek a new team as their original website construction team wasn’t even average — they were below average and that turned out to have costly ramifications.)

After that we automated sending thousands of billing notices they send out each week. This used to be done by hand, but now happens automatically, with each notice automatically customized to its recipient’s situation and details. As we write, we’re now working on a new system to radically change how the entire organization uses email as we’ve done for other clients, automatically ingesting hundreds of thousands of emails and attachments and linking them automatically to clients, client activity, and their case files. Later down the road we have discussed projects to automate their billing system, to integrate more closely and automatically with Docusign, and other projects.

Each of these projects went through a determine what to build, build, test, and deploy cycle. Each time we learned more about how better to do things for the next iteration.

We build large software systems in stages, with each stage delivering a working and valuable system. Users get new insight into what is possible once they start using a system, so we work to get to system use as quickly as possible. Experience with the first working parts of a large system gives users ideas to refine future portions, and building a project in stages makes progress visible, concrete, and more immediately useful.

3. Testing

Mighty Ant tests systems in many ways and at all stages of development. During design and specification we test out ideas with user feedback and system mock-ups, during system construction we use automated unit and integration testing, during deployment we do tests to confirm customer data migration integrity. But the separate "Testing" stage of development is the part of testing that takes place between construction of the system and deployment of it to users where users test out a system to confirm that it meets the business goals, and get a chance to start getting familiar with it before it is deployed to users.

With a mobile application this sort of testing is done by sending the mobile app to users who can test it out to confirm that all is well before it is deployed to one of the public app stores. With a web application the testing might be done on not-yet-public web pages that staff can access to test out the system, or, for larger changes, testing is done by users on a separate testing server entirely. For desktop applications, testing usually consists of bringing up the new application to test side by side with the old application still being used. Staff can test out the new system without being concerned about breaking anything or messing up any business data, and can try out new procedures in the new system while still having the old production system completely available to do their ongoing work.

Often when users are testing a system it will finally start to sink in how remarkably easier and more automated their jobs are about to get, and they’ll start to come up with dozens of new ideas for further automation. People already believed the new system or application would be great (otherwise they wouldn’t have paid to build it!), but once they start to physically see it in action, this information sinks in a new way. As all of these new ideas come up for future additions and improvements we record them to put into the next "determine what to build" project phase (as we don’t want to delay too much at this point because we’re about to get to "deploy to users" where the business starts reaping the rewards of its investment.

Once the users confirm that the system does what we set out to do, then we move on to deployment.

4. Deploy to Users

We build software so we can use it. "Deploy to Users" is the process of putting the software into use. For a new mobile application, it may just consist of submitting it for publication to the various app stores. For a major business system, deployment consists of user training (both on-site and remote), automated data migration to move business data from the old system to the new, and then very close support for users as they start to use the system daily to do their jobs.

Deployment to users is when the business starts to gain value for its investment. It’s also when users truly start to understand what has been built for them. A car designer may be able to picture a new car by looking at a dozen detailed blueprints of it. But normal people have to sit in the car and take it for a drive to get a feel for it. When they do, they start to understand how much better a car is than a very old horse (the feeding is much simpler. No more daily feedings and cleaning the stall or brushing the horse after it works — you just go to a gas station and fill up the car’s gas tank every couple of weeks.)

We provide training, support, bug fixes, and minor feature additions to help users adapt to the new system. We help users with any questions, and provide necessary documentation for both users and your IT folks that take care of your servers and network.

Maintaining Your Investment for the Long Haul

Ongoing maintenance keeps your mission critical systems in good health and delivering value to your organization. For different projects ongoing maintenance may include system hosting, management of automated backups, operating system and security update work, ongoing user support, and fixes for any glitches that may come up.

Mighty Ant DataWorks offers a variety of maintenance contract types covering everything from basic hosting, to ongoing system management, security management and incident response, to full application and ongoing user support agreements. None of these are required. You own the systems we develop for you, and you can support them as you wish. But many clients prefer to have their systems professionally managed and maintained, so they know they never have to worry. Clients with maintenance contracts also get preference in project scheduling for system improvements.

Mighty Ant maintains long term relationships with clients. The longest we’ve provided maintenance for a client is 26 years (we’ve been in business for 29.) We build our work and then suppport it long term to make sure your investment continues to pay off year after year.

We love making software!

Engineering is the application of scientific principles toward practical ends. If the engineering isn’t practical, it’s bad engineering. We love making software — making a practical difference in the lives of real people we work with. And our favorite part of the process is seeing the real business results people get from their new systems.