The short answer: We use what we build before anyone else does. Each piece of work starts as a written design, then a specification and a plan. It's built test-first, reviewed independently by several different AI models and by us, and merged once disagreements have been recorded and settled. It runs on our own servers, with storage that keeps snapshots, a private network between our sites and off-site backups that can't be altered.
Our How we build page says this in a few lines, and there's a short film there too. This article is the longer version, for the reader who has to assess a supplier: a technical lead, or whoever is doing the procurement. For each stage it sets out what we do, and then, separately, what a stage of that kind is for and what you could ask any supplier to show you.
Run it ourselves first
Everything on our site was built for Freestart's own work before anyone else saw it. Our own teams are the first users, and if it doesn't help them, it doesn't ship. CallHub, TrainingHub and ProspectHub are in use at Freestart, which means our own teams use them at work today.
Why this matters to a buyer is simple enough. A supplier that depends on its own software finds the faults first, and hears about them from colleagues who are trying to get their work done. Any supplier will tell you their software works. You learn more by asking who relies on it.
The six stages
| Stage | What we do | What it's for |
|---|---|---|
| Design | A written design | Agreeing what the change is for before any code exists |
| Specification | Then a specification | Stating the behaviour exactly enough to test |
| Plan | Then a plan | Putting the work in order, in small steps |
| Build | Built test-first | Proving each piece does what the specification says |
| Review | Several different models, and us | Catching what the builder missed |
| Merge | Disagreements recorded and settled | Making the change part of the product |
1. Design
Work starts as a written design.
A design, in the general sense, says in ordinary language what a change is for, what it will do, and what it won't. Writing it down first matters because words are the cheapest thing to change. A misunderstanding found in a design costs a conversation, and the same one found after the build costs a good deal more.
Ask a supplier: could I read a design for something you've built, and would I understand it?
2. Specification
Then a specification.
Where a design says what is wanted, a specification says exactly how the software must behave, case by case, in terms that can be checked. "Flag invoices that look wrong" is a wish. "Flag an invoice when its total differs from the purchase order" is a statement someone can test.
Ask a supplier: how do you get from what we said we wanted to something you can test against?
3. Plan
Then a plan.
A plan orders the work. Its main job is to break a change into steps small enough that each can be built, tested and reviewed on its own. A reviewer can read a small step properly, and a large one tends to be skimmed.
Ask a supplier: how big is a typical change by the time someone reviews it?
4. Build, test-first
It's built test-first.
Test-first means the test is written before the code it tests. The test describes what the software should do, and at first it fails, because the code doesn't exist. The code is then written until the test passes. Two things follow. Each piece of behaviour has a check that it works, and those checks stay in place, so a later change that breaks an earlier one is caught straight away.
Ask a supplier: when you change something next year, how will you know you haven't broken what works today?
5. Review
It's then reviewed independently by several different AI models and by us before it's merged.
The reason for more than one reviewer is the reason for a second opinion anywhere. Reviewers working independently tend to miss different things, so between them they catch more. The reason for people in the review is accountability: somebody has to stand behind what goes in.
Reviewers won't always agree. On our How we build page we put it this way: disagreements are recorded and settled, not skipped. A disagreement is evidence that something is unclear, in the code or in the specification, and waving it through leaves the problem in place.
Ask a supplier: who reviews a change besides the person who wrote it, and what happens when they disagree?
6. Merge
Merging is the point at which a change joins the main body of the product's code. Until then it sits to one side, where it can be tested and reviewed without affecting anything in use. In our process a change is reviewed before it's merged.
Ask a supplier: can anything reach the live system without being reviewed?
Why the order matters
In a process like this, each stage produces something the next one is checked against. The specification is checked against the design, the tests against the specification, the code against the tests, and the review looks at all of them.
Work in the opposite order, with code first and documents afterwards, and the documents describe whatever happened to get built. They can't tell you whether that was the right thing.
There's a commercial side to this as well. A written design is what makes a fixed price possible, because both sides can see what's being bought. The fourth article in this series makes that case.
Cite it or say so
One rule applies to what the software does, as well as to how it's built. Where software gives an answer, it shows what the answer rests on. Where the evidence isn't good enough, it says so.
PlanningAssist, which is in beta, is the clearest example: it answers with numbered sources. The first article in this series describes how it finds them.
Our own infrastructure
We run our own servers, with storage that keeps snapshots, a private network between our sites, and off-site backups that can't be altered. We test restores rather than assume them.
Here is what each of those terms means, in general, and why a buyer should care.
- Storage that keeps snapshots. A snapshot is a record of the data as it stood at one moment. If something is deleted or damaged, the earlier state is still there.
- A private network between sites. Servers in different places can talk to each other without that traffic being open to anyone else.
- Off-site backups that can't be altered. A backup kept somewhere else survives the loss of a site. One that can't be altered also survives a mistake or an attack that would otherwise overwrite it.
- Tested restores. A backup has only been proved when someone has restored from it. Plenty of organisations find out that theirs doesn't work on the day they need it.
What we build for other businesses is looked after in the same place. We run and maintain what we build, on the same infrastructure we use for our own products.
Ask a supplier: where does it run, who looks after the servers, and when did you last restore from a backup?
What we leave out
We don't put numbers on our site we can't stand behind, and we label what isn't finished.
The labels mean what they say. "In use at Freestart" means our own teams use it at work today. "Beta" means it's public and still changing. "In development" means it isn't finished. A buyer should be able to tell from a supplier's own website which of its products exist.