Internal systems development: ERP, CRM and operations built on your processes.
We start where the spreadsheet breaks: concurrent users, permissions, history, reporting, and everyone sees what belongs to them. If you run an ERP, it is built beside it; if you do not, this becomes the base of your system.
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 writingFixed quote after scoping
One process end to end, with the roles and the training included.
How the process works today
The company's operating logic lives in one person's mega-spreadsheet, undocumented.
Everyone has heard a bad ERP rollout story, and it holds companies back more than the current state does.
Approvals go by email, and nobody can say whose desk one is sitting on.
You have a system, and the real work happens beside it, because the system was not built for this process.
Which one is your situation?
Stock, orders and clients in three places
One system on the company’s shared data: stock, orders and clients work from the same records, each person in their own view.
You have a system; the work happens beside it
The missing piece beside what you have: what your current system cannot do, we build and connect to it.
Approvals stall somewhere in email
Approval workflow: a request moves through the roles, showing whose desk it is on and since when, with a log.
One process lives in one file
The same logic as a system: several users, a history and permissions, instead of the shared spreadsheet.
One purchase request, all the way to approval
The selected request has cleared finance, has waited two days with the manager, and every step is logged.
Purchase requests
- RequestBarcode scanner for goods-inK-118DepartmentAmountWhere it isfor two days
- RequestShelving, hall BK-117DepartmentAmountWhere it issince today
- RequestDesign software licenceK-116DepartmentAmountWhere it issupplier quote missing
Barcode scanner for goods-in
K-118 · Warehouse · €465
- Monday 9:12
- Monday 15:40
- waiting for two days
- after approval
Log: four entries, each timestamped
Your existing systems stay; we build the missing part.
- 1Your invoicing tool and the system work from the same data, with nothing retyped by hand.
- 2Where the other system allows no direct connection, scheduled exports and imports carry the data across.
- 3What sells in your store shows up in stock, without a round of emails.
- 4The history stays in the system, including when someone leaves the company.
What the first stage of the rollout includes
- A process map: who does what today, and where the work stops
- A written, scheduled proposal for the first process
- The first process taken live, permissions included
- Each connection priced line by line, system by system
- Training for the people who run the process every day
- Source code, credentials and documentation at handover
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.
How the system replaces the spreadsheet
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
A spreadsheet, a boxed product, or your own
Most teams start with a spreadsheet or a ready-made, per-seat tool, and for a stable process that is the right answer.
A shared spreadsheet
A boxed product
An in-house developer or freelancer
Brecon
What it costs as the team grows
Nothing, while one person runs it. Then the cost of the errors once two people write to it.
A monthly fee per seat, and every new colleague is another line.
A salary or an hourly rate, open-ended, and the estimate is theirs.
One figure in the proposal, through to the end of the rollout, and if we slip, the next payment waits.
What happens when your process differs from the template
You rewrite the formula, and nobody knows what changed or when.
Workarounds, or you bend your process to fit the box.
They build it when they have time, and the knowledge leaves with them if it is not written down.
The system is built on your process, and handover includes the source code, the accounts and the documentation.
Who owns the data and the process
In one file anyone can overwrite, and keeping the versions straight is on you.
You can export the data; the process you built inside it stays there.
Depends on the contract, and one sentence in it decides.
Yours, with the accounts, on the final invoice, and your data stays in your own database.
When it is the better choice
When one person runs it, without exceptions, and the team is not growing.
When your process is stable and standard, and a handful of people use it.
When development will run for years, and someone can direct it daily.
When one process has to come out of the spreadsheet, and the rest can follow at your own pace.
What it costs as the team grows
- Brecon
- One figure in the proposal, through to the end of the rollout, and if we slip, the next payment waits.
- A shared spreadsheet
- Nothing, while one person runs it. Then the cost of the errors once two people write to it.
- A boxed product
- A monthly fee per seat, and every new colleague is another line.
- An in-house developer or freelancer
- A salary or an hourly rate, open-ended, and the estimate is theirs.
What happens when your process differs from the template
- Brecon
- The system is built on your process, and handover includes the source code, the accounts and the documentation.
- A shared spreadsheet
- You rewrite the formula, and nobody knows what changed or when.
- A boxed product
- Workarounds, or you bend your process to fit the box.
- An in-house developer or freelancer
- They build it when they have time, and the knowledge leaves with them if it is not written down.
Who owns the data and the process
- Brecon
- Yours, with the accounts, on the final invoice, and your data stays in your own database.
- A shared spreadsheet
- In one file anyone can overwrite, and keeping the versions straight is on you.
- A boxed product
- You can export the data; the process you built inside it stays there.
- An in-house developer or freelancer
- Depends on the contract, and one sentence in it decides.
When it is the better choice
- Brecon
- When one process has to come out of the spreadsheet, and the rest can follow at your own pace.
- A shared spreadsheet
- When one person runs it, without exceptions, and the team is not growing.
- A boxed product
- When your process is stable and standard, and a handful of people use it.
- An in-house developer or freelancer
- When development will run for years, and someone can direct it daily.
Who an internal system fits, and who not
This fits you if
- Your processes break down into roles and permissions.
- You run several systems, and people currently do the moving between them.
- Reporting is assembled by copy-paste, and by the time it is ready it is stale.
We would point you elsewhere if
- Your ERP already does what you are asking for and needs configuring. We say so, and we do not build a layer on top of it.
- One process needs automating rather than the whole operation. An AI automation or a small internal tool costs less.
If you are building a product for your own customers, that is web application development.
What we built
- Gloster Content EngineAn internal AI content platform for a software company: campaigns, article drafting, an approval round and multi-language publishing in one system, with roles. The screen shows which piece is with whom and when it can go out. It is live.Internal system
88%
of audited business spreadsheets contained at least one error, and most stay hidden until they cost money.
Panko, University of Hawaii: 113 real operational spreadsheets across seven field audits.
Companies we've built for
How we work
An internal system from process review to training
- One process, one fixed price in the proposal, to the end of the rollout
- Training and rollout are part of the proposal
- The code and the data are yours, and the system runs if we step away
In writing
Fixed quote 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 must it fit? Each connection is priced by how open the other system is.
Request a process reviewWhat happens after launch
An 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
A clean handover, a watched launch
Source code, credentials and documentation in your hands, and we watch the first week with you, measurements included.
Every month
Maintenance that keeps it moving
Updates, fixes, extensions, and an eye on the measurements.
If something breaks
You write, we answer
A first reply within 24 hours on working days, to every enquiry.
What to ask before a rollout
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. 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 directly or through an export. Replacing the ERP is something we recommend only when it genuinely costs less. The price list says "Fixed quote after scoping", because the number of processes decides it, and the first process gets a fixed-price proposal.
Where the system allows a direct connection (Shopify, Google Workspace, most invoicing platforms), we use it. Where it does 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 system is built in modules, 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.
Yes. When client management is the main problem, custom CRM development is built for it: the same approach, shaped around the client record and your sales steps. There too we start with one process and a fixed-sum proposal.
Start with the most expensive process
In half an hour we find which process eats the most manual hours, and the proposal comes from the survey that follows.
- 12+ projects deliveredevery one on deadline, in production
- Fixed price and deadlinein writing, and if we slip, the next payment waits
- Reply within 24 hourson working days, to every enquiry