SVC-01 / Software Development
Software Development
Custom web and backend systems built to your operations, not to a template.
The situation this addresses
Your process runs on a spreadsheet that three people understand, and the tool you bought models someone else’s business. Every month you pay for the gap in manual work.
How we approach it
In order.
- 01Sit with the people doing the work and write down what actually happens, exceptions included.
- 02Model the data first. Most bad systems are a bad schema behind a good front end.
- 03Ship a thin slice to production early, then widen it.
- 04Hand over the pipeline, the tests and the runbook — not just the repository.
What this looks like in practice
Most of the systems we are asked to replace are not bad software. They are good software pointed at a business that has since changed shape. The finance tool was right when there were twelve people and two product lines; now there are ninety people, four lines, and a spreadsheet doing the part the tool never learned.
So the first week is not architecture. It is sitting with the people who actually run the process and writing down what happens — including the parts nobody documented, the workaround for the customer who insists on being invoiced differently, and the manual check that quietly catches a class of error every month. Those exceptions are the system. A rebuild that models only the happy path is a rebuild you will be working around within a year.
Then the data model
We design the schema before any interface, and we show it to you in plain language: these are the things your business has, these are the rules about how they relate. If that description is wrong, it is cheap to fix now and expensive to fix after six months of code sits on top of it.
Then production, early
The first release goes to real users on a narrow slice — one team, one workflow, real data. It is deliberately small enough that being wrong is survivable, and real enough that the feedback is worth something. We widen from there.
You finish the engagement owning the repository, the pipeline, the tests and a runbook written for the person who will be on call at 3am, who may not be us.
What you end up with
Three things you can point at when it is finished.
SVC-01-01
A typed API and data model you own
SVC-01-02
Web application and internal admin tooling
SVC-01-03
Deployment pipeline, tests and a written runbook
We provide
- Architecture, schema and application code
- CI/CD, environments and monitoring
- Documentation and handover sessions
You provide
- Access to the people who run the process today
- One named decision-maker for scope calls
- Credentials for the systems we integrate with
- Engagement shape
- Fixed-scope build, or an embedded team working alongside yours.
- Indicative duration
- 6–14 weeks to a first production release. Confirmed in writing after the discovery call, not before.
What usually sits next to it
Rarely bought alone.
SVC-02
Technology Consultancy
Architecture, audits and roadmaps — before you commit budget to a build.
Read the service detail
SVC-05
Automation
Workflow, integration and process automation that removes manual handoffs.
Read the service detail
SVC-07
Web & Mobile Applications
Cross-platform products with AI capability built in from day one.
Read the service detail
Next step
Bring us the process, not the specification.
A discovery call is 45 minutes. You get a written summary of what we heard and what we would do about it, whether or not you go further with us.