Everything from one team
Design, build and operations with the same team, from the first call to launch.
We start where the spreadsheet breaks. The layer spreadsheets stand in for today is built beside the ERP you already own: concurrent users, permissions, history, reporting, and everyone sees what belongs to them.
12+ projects delivered
every one on deadline, in production
Fixed price and deadline
in writing, and if we slip, the next payment waits
Reply within 24 hours
on working days, to every enquiry
In writingQuoted after scoping
One process end to end, with the roles and the training included.
How the process works today
How the company operates lives in one person's mega-spreadsheet, with no documentation.
The last ERP rollout was expensive and late, and half the team still works from their own sheet.
Approvals run over email, and nobody can say whose desk a request is sitting on.
You have a system, and the real work happens beside it, because going around it is easier than using it.
Which of these is your project
Inventory and goods-in
Whatever arrives at the warehouse is recorded in one place, stock follows on its own, and you hear about it before it runs low.
CRM and client records
A client’s history, the open quotes and the next step in one place, with a record of who spoke to them last.
Approval workflow
A request moves through the roles, you can see whose desk it is on and since when, and a log keeps who approved what.
One process that lives in a spreadsheet today
The same logic, with several users, a history and permissions, instead of one shared file.
Your existing systems stay. We build the layer that is missing.
Example
For a 30-person manufacturer we would start with goods-in: delivery-note lines scanned by barcode, discrepancies visible immediately, and nothing moving on without approval from the warehouse lead. Stock updates from that, and purchasing sees what is missing in the system rather than in an inbox. Reporting goes into the next stage.
The system’s technical base
In an internal system the real question is what happens when two people touch the same row at once. A shared spreadsheet becomes two versions at that moment; PostgreSQL keeps one order.
We walk through where data gets retyped by hand and who waits on whom. At the end we say which process is worth starting with.
We map who does what today and where the work stops, and you get a phased, itemised proposal on top of it. That price holds to the end of the rollout.
The first process is built all the way to production, roles included. The people who use it try it while it is being built.
Training is part of go-live, and we keep following how the process changes.
Call
Scoping
Build
Live
Who should build it
Most teams start with a ready-made, per-seat tool, and for a stable process that is the right answer. This question comes after.
In-house developer
Freelancer
Hourly agency
Brecon
Who is accountable for the deadline
You are. They estimate; your company carries the consequence.
Whatever you agree. With no deadline in writing there is nothing to hold.
An hourly rate covers the effort; the date stays an estimate.
Us. The first process has its deadline in the proposal, and if we slip, the next instalment waits.
What happens if the person leaves
The knowledge leaves with them unless it was written down. A new hire, a new ramp-up.
One person, one calendar. If they disappear, the project stops.
People can be swapped, and the ramp-up still takes time.
Handover includes the source code, the accounts and the documentation, and training is part of the rollout.
What happens to the code
Yours, as it is written.
Depends on the contract. One sentence in it settles the question.
Depends on the contract, and licences and accesses are part of the question.
Yours, with the accounts, on the final invoice, and your data stays in your own database.
When this is the better choice
When development runs for years and someone is there to direct it daily.
For small, precisely described work this is often a sound choice.
When the scope only becomes clear as you go and you can carry an open budget.
When one process has to come out of the spreadsheet, and the rest can follow at your own pace.
This fits you if
We would point you elsewhere if
If you are building a product for your own customers, that is web application development.
What we built
88%
of business spreadsheets contain an error, and most of those stay hidden until they cost money.
This figure comes from industry research.
Companies we've built for
On every project
Everything from one team
Design, build and operations with the same team, from the first call to launch.
Your goal sets the bar
The first call is about what you want to achieve; if less will get you there, we say so.
Tested before it goes live
We measure what we hand over before launch, and watch the first week with you, measurements included.
How we work
The proposal is itemised: what we build, by when, for how much.
In writing
Quoted after scoping
One process end to end, with the roles and the training included.
How many processes, how many roles, and how many existing systems it has to fit. Integration is priced by the other side's API.
Request a process reviewAn internal system is worth something for as long as it follows the process it was built for, so that is what the work continues on.
First month
Source code, credentials and documentation in your hands. We watch the first week with you, measurements included.
Every month
Updates, fixes, extensions, and the measurements watched as your product grows.
If something breaks
A first reply within 24 hours on working days, to every enquiry.
We start with one process, the one where the manual hours go, and take that live. If it works, the next one follows. Every stage pays for itself on its own, and you can stop after any of them. The code and the data are yours, and the system keeps running if we step away.
We sit down with the people who do the work today, and we start with one process rather than the whole company. Training and rollout are in the proposal, and in the first weeks we watch how it is used and adjust the screens to match.
If three or four people run a stable process with no exceptions, a ready-made tool is cheaper and faster, and that is the answer the review will give you. It runs out where the process is full of exceptions, where the number of editors keeps growing, and where permissions are already being worked around. In a system of your own, the data and the interface both stay with you; in a ready-made tool you can export the data and leave the process you built behind.
In most companies the ERP handles accounting and stock well, and spreadsheets cover what it misses: goods-in, approvals, custom reporting. We build that layer and connect it to the ERP over an API or an export. Replacing the ERP is something we recommend only when it genuinely costs less. The price list says "Quoted after scoping", because the number of processes decides it, and the first process gets a fixed-price proposal.
Where there is an open API (Shopify, Google Workspace, most invoicing platforms) we connect directly. Where there is not, we work with scheduled imports and exports, and a transfer that stalls is retried, with a record of what went through and what did not. The review covers every system you run, your accountant's software included, and the proposal prices each integration on its own line.
Yes, and we recommend it. We start with one process, at its own price and deadline, and at the end that process runs in production. The next one is a separate proposal on the same logic, so you set the pace of the spend.
At handover you get a maintenance quote of its own: updates, fixes and extensions as new processes or roles come in. The architecture is modular, so a new part does not rewrite what exists. The code is yours, so an in-house developer or another team can carry it on.
Most of it early on: a few hours of conversation with the people who run the process daily, because their workarounds are the real specification. During the build we ask at decision points. Training is part of handover, so your team is not left alone with a new interface.
In half an hour we find which process eats the most manual hours. A survey follows, and the proposal comes out of it.