A technical specification is often seen as red tape that contractors impose to cover themselves. In practice it is the other way round: a project without a specification protects the contractor, while a project with one protects the client. Until the scope is fixed, the argument "was this in the estimate or not?" is won by whoever writes the code.
What the technical specification includes
- A detailed written specification: scenarios, roles, rules and edge cases.
- An interface model: which screens exist, what blocks they are made of and how the user moves between them.
- A data model: which entities exist, how they relate and which combinations are impossible.
- Contract preparation for the agreed scope.
- A development budget estimate based on fixed boundaries rather than intuition.
How the document is structured
We write specifications along lines close to an SRS and the ISO/IEC/IEEE 29148 standard. Not for the sake of form, but so the document can be used to assign tasks, estimate them and accept the work. Inside: a general description of the system, functional and non-functional requirements, business objects and their content, data constraints, architecture decisions, a description of the infrastructure and the admin side, and acceptance criteria.
We also record the quality requirements that are usually "taken for granted": security, backups, speed, supported devices, analytics. They affect the budget, and if they are not in the document, they are not in the estimate either.
Why the data model matters more than the feature list
Features change; data stays. If the relationships between entities are described wrongly at the start, every new feature costs more than the last one, because it has to be squeezed into a structure that resists it. This is where what people later call technical debt is born, even though nobody borrowed anything: someone simply did not spend fifteen minutes thinking about a relationship.
Data model design is covered in more detail in the article on server-side business logic, but the decision is made here, at the specification stage.
What you get at the end
A package of documents and models sufficient to start full-scale development. Crucially, this package works without us. You can take it to tender, switch contractors or hand the work to an in-house team and receive comparable proposals, because everyone is pricing the same thing. A well-written specification also protects the client legally: acceptance is based on criteria in the document, not on what people remember.
How much does a technical specification cost?
A written specification with interface and data models costs $800. If you order prototyping straight away, the specification is included at no extra charge: you save $800, and the combination of specification, architecture, database schema and a small visual prototype costs $2400. This package usually takes 2-3 weeks and suits projects that will continue as fixed-price development.
For systems with complex business processes there is a full package for $7600: specification, detailed specs, a database with its management system and part of the interfaces (forms, lists, charts, media blocks), which are later reused in the product. It takes up to two months.
If you already have a specification, you usually do not need a new one. We audit it: we check completeness and consistency and draw up a list of clarifications and assumptions. For an existing system the entry point is priced the same way: a written audit costs $800.
What breaks if you skip this stage
The budget estimate becomes fiction. Any figure named before the boundaries are fixed is a bet, not a calculation, and it is usually the client who pays for it: with money beyond the estimate or with features cut at the end.
You can start with a fixed budget and no specification, but the risk of underestimation, disputed expectations and frequent changes rises sharply. In that case we fix not "the whole product out of thin air" but only the next stage, its boundaries and the rules for handling changes.
An example from our work
For the international bus carrier LEX, our part of the work ended before the first line of production code. We analysed sales and booking, wrote a standardised specification, designed the architecture and key algorithms, passenger screen wireframes, the carrier's admin workspace and an API prototype in Swagger.
Other contractors handled the build, and that is the best test of a specification: the logic we laid down made it into the product. The home page had route search by "from", "to" and "date", currency and language switches, a passenger account and a discount promo code.
Another example: for the manufacturer Sklo, the audit and prototype led to a 98-page specification. It is not a wish list but an engineering document for three connected apps.
Where to go next
Next comes prototyping for $2400: the specification comes to life as a clickable version, and the remaining disagreements become visible before the first line of production code is written. The previous step is consultation and modelling. The full map is in the app development strategy.
Discuss the scope of your specification at a free consultation with an architect. After the call you will receive a stage-by-stage estimate of cost and timeline.
