Documentation is unnecessary right up to the day the person who kept the system in their head goes on holiday, joins another company or simply forgets why it was built that way five years ago. From that day, every change starts with digging, a new contractor asks for an audit before quoting, and staff learn the system from colleagues' retellings.
Documentation turns what individual people know into a company asset. This is a track from the corporate growth block: it is added once the product is live and moving from MVP to MMP and MLP. The guide price for the track in the Ingello price list is $4,700.
What an undocumented system costs you
- Every estimate for a change starts with studying the code, and you pay for a contractor to understand what already exists.
- A key developer becomes irreplaceable, and their departure halts product development.
- A newcomer takes weeks to get into the project, asking questions of people busy with their own work.
- An external partner cannot connect to your API without calls and verbal explanations.
- Support answers the same user questions again and again, because there is nowhere to read the answer.
There is a direct financial effect too. Under our rules, an audit of an existing system can be skipped only if there is current documentation of business processes, architecture and the codebase, plus a normalised data schema. Without them, any new team first has to reconstruct the picture, and you pay for that work.
What the work includes
The price list describes the track in three lines: technical documentation, user documentation, and a foundation for long-term support and development of the project.
Technical documentation
- Architecture: what parts the system consists of, how they connect and where they are deployed.
- Data model: tables, relationships and the meaning of fields in plain language.
- An API description for the front end, the mobile app and partners.
- Business rules: statuses, roles, calculations and what happens at each event.
- Deployment and recovery procedures after a failure.
User documentation
- Role-based guides: sales manager, operator, accountant, administrator.
- Step-by-step descriptions of routine operations with notes on each screen.
- Answers to the questions support receives most often.
A foundation for support and development
- A single place to store it, clear to both developers and the business.
- An update rule: a change to the system is not finished until its description is updated.
Document decisions, not features
A list of screens goes out of date within a month. What does not go out of date is a record of why a particular approach was chosen and what was considered instead. It explains the system to a newcomer faster than reading the code, and it protects against repeating mistakes the team has already worked through once.
The user part saves on support
Especially in systems with high frontline staff turnover. A guide tied to a role (who you are in the system, where to start, what to do step by step) is cheaper than repeating live training for every new employee.
What you get
- Independence from any single developer and any single contractor.
- A basis for a technical specification for changes without a repeat audit.
- Faster onboarding for new people, both in the development team and among system users.
- An API description that lets partners connect on their own.
How much it costs and what drives the price
The guide price is $4,700 for the track. Scope depends on the number of modules, roles and integrations, and on the starting point. If the system was designed with us, the foundation is the technical specification and the models created at the start. If the project came from another team, an audit is needed first ($800 for a written report or $2,400 with an early prototype of the change): it reconstructs the architecture, key business processes and data model, and those materials become the skeleton of the documentation.
What breaks if you cut corners
- One person leaving turns into the project stopping.
- Every next change costs more, because it starts with studying what was already done.
- Switching contractors requires an audit you end up paying for again and again.
- Documentation written once as a box-ticking exercise drifts away from the system within six months and starts to mislead.
An example from our practice
In our Fractal technology, part of the documentation is not written by hand but built from the same description as the code. For each model, a REST API is generated with Swagger documentation, so a front end or mobile app can connect without verbal explanations. Business logic directives written into a screen description are registered in the documentation and turned into method stubs. That is why the description does not drift from the system: it is the system's source.
For corporate software built for a German holding company, this description language was used for entities, the database, the API and part of the documentation. More in the case study on the AI developer that writes to an architecture.
Where to go next
Related tracks: refactoring and test automation. Project acceptance is covered in the testing and handover stage. The map of all stages is in the app development strategy.
In a free consultation, an Ingello architect will review what is already written down about your system and what lives only in people's heads, and propose an order for documenting it. Afterwards you receive a price and timeline estimate broken down by stage. Discuss ongoing support.
