A House

I like using a house as an analogy when discussing custom web application development as it covers a very similar set of skills.

The Client

First we have the property developer, this is the visionary, the person who conceives of building the house, what the overall tone and concept is going to be and its purpose. They are also the one funding it or obtaining funds for it. For our analogy they are the client, the entrepreneur. They have an idea but they don’t have the technical knowledge so see it through alone so they look for those with the appropriate skillset to advise and help them implement their idea.

The Solution Architect

For a housing project, the property developer would never head out and pick up a team of builders and just start constructing. Yet for some reason this is still quite common for custom application development. At best it’s not cost-effective, at worse it can be a disaster both for finances and for the client’s image.

A crucial step to building a house is to have a solid plan. Such a plan includes the overall design, the building blueprints, the internals such as water and electric lines and outlets, risk assessment and mitigation, and much more. One of the purposes is to find and solve problems before they occur. For a house this is done by an architect and their technical engineer. For custom application development this is done by the Solution Architect.

The best Solution Architects are those with a deep technical understanding and years of experience in the required technologies, the user experience and the business logic of the project. Each type of knowledge is crucial and a requirement for an SA as they need to be able to understand and view the project from as many different angles as possible.

They are able to apply all this knowledge and create the application in their mind without programming anything. They can go through many different iterations of how to program different features and look it at in detail as well as part of the big picture. They need to be able to see how it will be programmed, how the user will experience it and if the cost/effort for a feature justifies the business result of it.

The developers

Once the plans are complete the client can bring them to a construction company and work can get started. For our analogy this is bringing the SA document to a development agency who can then implement the application according to the plan, timeline and phases.


The interior decorator works on the design of the house as the occupants will experience it. Their role is to ensure the house is aesthetically pleasing as well as functional to the user. This is what a designer/UX specialist does for an application.


Some other roles that fit the analogy are:


So is it efficient to start with working on documentation instead of just “getting the job done”? Let me explain this with an example or two.

A simple 1-page website. Let’s say you go directly to a developer. They quote you 2 hours of work and you approve it. But the result doesn’t work on mobile devices. This would be one of the first questions an SA asks. Many developers would also ask this but not all of them and therein lies the risk. There are many more such questions that a developer might ask but an SA WILL ask. Where is the target audience - local or global? How frequently will you need to make changes? As well as questions that many developers probably will not ask such as: how are you going to promote this website and what is your expected ROI?

A one-hour meeting and small SA would make sure all these questions are asked, and answered. The document can then go to the developer without any assumptions being made and the result will not have any surprises.

The cost difference at this level would be minimal. Financially, it might even be cheaper going directly to the developer and skipping the SA but it is likely that you would have missed your deadline because of the unforeseen changes that had to be made.

For a larger 4-5 month project this risk increases exponentially. For every function added there are multiple ways it can be implemented and multiple ways it will affect other functions in the system depending on how it is implemented. The cost difference an SA can make in this scenario easily runs into the thousands of dollars. Not just by reducing the risk of issues in the code later or pointing out business risks that may have been overlooked, but also looking at alternative approaches such as an MVP (Minimal Viable Product). Basically a simple implementation of the project that can be run with a test group to establish if the planned features are really what the users’ want. This can avoid spending money on developing features the users’ don’t want and potentially miss features that they do want.

Final Advice

Ask questions, ask as many as possible and from as many people as possible, because better to ask them up-front instead of when the project is finished.