Every product in our group started as something a person did by hand, enough times that encoding it became worthwhile.
That order — operation first, software second — was not a strategy. It was a consequence of running a services business and getting tired of the same steps. But having been through it several times now, I think the order matters more than it appears, and I want to describe what it actually looks like.
The first version is a person and a checklist
A company formation, done manually, is roughly: collect the customer's details, verify their identity, check name availability, prepare the incorporation documents, submit them, receive the certificate, deliver the document pack, and set up the compliance calendar.
The first version of that is a person and a checklist. It is slow and it does not scale, and both of those are fine at the start, because it is doing something more valuable than processing formations: it is discovering what the process actually is.
You cannot learn this by designing it. The checklist you write before doing the work is always wrong in the same way — it covers the path where everything goes right, which is not where the time goes.
Automate the measurement before the work
The instinct after a hundred formations is to automate the step that feels most tedious. That instinct is usually wrong, because "feels tedious" and "consumes the most time" are different things.
What we found more useful was to instrument the process before automating any of it. Record when each case enters each stage and when it leaves. After a few weeks you have an actual distribution rather than an impression.
Ours was not what we expected. The steps that felt slow — preparing documents, submitting them — were fast and predictable. The time was going into waiting: waiting for a customer to send a document, waiting for a document to be readable, waiting for someone to notice a case was stuck.
That points at a completely different first build. Not document generation. Notifications and state tracking.
Model the state machine, not the happy path
The thing that turns a checklist into software is naming the states.
A formation is not a sequence of tasks. It is an object that occupies one state at a time and moves between them: submitted, awaiting documents, documents received, in review, submitted to registrar, incorporated, documents delivered, active.
Once states are explicit, several things become possible that were not before:
- You can ask how many cases are in each state, which is the first genuinely useful operational metric.
- You can attach a duration to each state and alert when one is exceeded.
- You can tell a customer where their case actually is.
- You can find the stuck cases without a person reviewing every open file.
The states are also where the exceptions live. Awaiting documents needs to distinguish "we have not asked yet" from "we asked and they have not replied" from "they replied and the document was unusable". Each needs a different action.
Extract the pieces that are not about formation
This is the step where a services business becomes an infrastructure business, and it is easy to miss.
Look at the formation state machine and notice how much of it is not specific to formations:
- Collecting structured information from a customer
- Verifying an identity document
- Reading data out of a corporate document
- Storing a document securely and delivering it under control
- Tracking a recurring obligation with a deadline
- Notifying someone that an action is required
None of those are about company formation. They are the general capabilities that a formation happens to need — and that a verification product, or a payments product, or a benefits platform will also need.
Recognising that is what turns the second product from a rewrite into an assembly.
Build the second product before generalising
There is a strong temptation, at exactly this point, to stop and build the platform properly. Take the pieces, generalise them, and then build products on top.
In our experience that produces a platform shaped by imagination rather than use. You cannot tell which parts of a capability are genuinely general from one example. One example gives you a thing that works once.
The more reliable sequence is to build the second product using the pieces as they are, tolerate the duplication, and let the second use case tell you where the real seams are. The interface that survives two real consumers is worth extracting. The one designed for hypothetical future consumers usually is not.
Keep the manual path working
An automated workflow with no manual override is fragile in a specific and predictable way: the first case that does not fit blocks completely, and the only resolution is a code change.
In a formation pipeline, cases that do not fit are routine. A name gets rejected. A document arrives in an unexpected format. A registrar raises a query. If the only way through is to deploy, operations stop while engineering is paged.
Every automated stage should have a manual counterpart that a trained operator can use to move a case forward, and that override should be recorded like any other transition — who did it, when, and why.
This is also, incidentally, how you find the next thing worth automating. The overrides cluster.
Where this sits at Dorsko
This is a description of how the group actually developed. Formation workflows became anasirket and Dorsko Formations, both live. The document handling underneath them is becoming DorskoVerify. The payment operations around them are becoming DorskoPay. Both are in development.
The sequence matters more than the destination: the software exists because the operation existed first, and it does the things it does because we watched where the time went.