Services
What we build, and how a project actually runs
01What we build
Applications that carry a real business process
These are the shapes of work we take on most often. Every one of them started life in somebody's workbook.
Quoting and estimating
Configure a scope, price it against current material and labor rates, produce a proposal, and keep every revision. The estimate stops being a file and becomes a record.
Cost and pricing models
The calculation logic sitting in a thousand linked cells, rebuilt as code that can be tested, versioned, and explained. When a number changes, you can see which input moved it.
Approval and review workflows
Who has to sign off, in what order, and what happens when they do not. Routing, status, and a record of the decision, instead of a chain of forwarded email.
Inspection and compliance records
Structured capture with validation at the point of entry, so the record is complete and legible when an auditor or a customer asks for it two years later.
Scheduling and capacity planning
Jobs, people, and equipment against time, with the constraints written down rather than held in one person's head.
Internal reporting
Reporting that reads from the live application rather than from a monthly export somebody has to remember to run.
02What changes
The spreadsheet was never the problem. Its limits were.
Excel is genuinely good software. It stops being the right home for a process at the point where several people depend on it and the cost of a mistake gets real. Here is what an application gives you that a workbook cannot.
Copies fork off the master and quietly stay on old rules
One set of rules, so a quote cannot be built on a stale copy
A file-level change log at best, and only if it is hosted somewhere that keeps one
Every change attributed to a person and tied to the record it changed
Anyone who can open the file can edit anything in it
Access by role, so people see and change what they should
A typo in a cell quietly propagates into the total
Validation at entry, so bad data does not get in
Re-keyed by hand into the ERP or the accounting system
Connected to the systems you already run
Backed up if somebody remembered to back it up
Managed hosting, real backups, and tests that run on every change
One thing we keep deliberately: Excel import and export. People who work in spreadsheets are usually fast in them, and telling them to stop is a good way to have your software quietly abandoned. Bring a workbook in, take one out, and let the application be the place the numbers actually live.
03How it runs
Small first version, in front of real users, quickly
We do not open with a six month discovery phase and a document nobody reads. The goal is working software in the hands of the people who do the job, early enough that their reaction still shapes it.
- 01
Read the actual spreadsheet
Not a description of it. The file itself, plus a conversation with whoever maintains it. We parse the workbook into a dependency graph so we can see every rule it contains, including the ones nobody remembers putting there. That person knows every exception and workaround, and those exceptions are the requirements.
- 02
Agree the smallest useful first version
The slice that replaces something real rather than demonstrating everything shallowly. We write down what is explicitly not in it, which is usually the more useful list.
- 03
Build it properly the first time
Real backend, real database, authentication, tests, and deployment automation from the start. Retrofitting those onto a prototype costs more than doing them up front.
- 04
Put it in front of the people who do the work
Where we find out which parts of the old process were load bearing and which were habit. Expect the first version to be wrong somewhere specific. That is the point of shipping it.
- 05
Iterate against use, not against a plan
Adjust based on what people actually do with it. The next thing to build is usually obvious once the first thing is live.
- 06
Hand over, or keep running it
Your choice. Documented and handed to your team, or we maintain and host it. Either way the code and the data are yours, and there is no lock-in dressed up as a support contract.
04The cost already on your books
You are already paying for software maintenance
This is the part that tends to go unexamined, because it never appears as a line item. A spreadsheet that runs a real process needs maintenance, and somebody is doing it. Not the pricing logic, which at least is the domain expert's actual expertise. The other work: fixing the layout after a column got inserted, rebuilding the print view so the quote fits on a page, chasing a reference error somebody introduced, making the totals line up again, reformatting for a customer who wants it a different way.
That is software maintenance. It is being done by the people you hired to sell, to estimate, or to engineer, using none of the tools that make maintenance survivable, and instead of the work that actually brings in revenue.
It is also invisible in a way that a vendor invoice is not. Nobody approves it, nobody measures it, and it grows quietly as the workbook accumulates edge cases. When people say a spreadsheet is free, this is the cost they are not counting.
The question is not whether you are going to pay to maintain this process. You already are. The question is whether that work is done by your revenue-generating people, at random, with no tests and no way to undo a mistake.
05Cost
Custom software at a price that competes with off-the-shelf
Custom development has a reputation for being the expensive option, and traditionally it earned it. A bespoke application meant a large team billing for a long time, which is why most businesses settle for generic software that fits awkwardly.
We work differently. A significant part of our build and test process is automated, including heavy use of AI-assisted development, which means a small team delivers what used to take a much larger one. The saving shows up in the quote rather than in the margin, which is how we end up competitive with a per-seat SaaS subscription you would be renting indefinitely.
We would rather scope honestly than win on a low number and discover the problem later, so pricing comes after we have looked at the real process. If a project is not worth doing at the price it actually costs, we will say so.
On your data
Automation is how we keep the price down, and it does not mean your business information gets scattered across every model and service on the market. Customer data stays inside the boundaries we agree with you. Where a project genuinely calls for a model-backed feature, we tell you exactly what data it touches and where it goes, before we build it.
In fairness to Excel
Modern Excel is not as helpless here as software vendors like to imply, and it is worth being straight about that. If your workbook lives in SharePoint or OneDrive, Excel for the web can show you cell-level changes with a name and a timestamp, and it keeps file versions you can roll back to. That is genuinely useful and it is more than most people realize they have.
Three things limit it. The first is that it only applies if the file lives there. The workbooks we are usually called about sit on a shared network drive or in an email thread, where none of it applies.
The second is that version history tracks one file. The moment somebody copies the master to write a quote, and then copies that quote next month because it is already filled in, the copy is a new file with a fresh history and no recorded link to where it came from. It can sit four revisions behind the master indefinitely and nothing will say so. Document management systems in other industries do track that lineage. Excel and SharePoint do not.
The third matters even when everything is hosted properly. A change log is not an audit trail. It can tell you a cell went from 0.12 to 0.14. It cannot tell you that the escalation rate on a specific estimate was changed, by whom, against which approval, and what the quote looked like before and after. It also ends the moment somebody downloads a copy to work on at home. If the record has to hold up to a customer dispute or an auditor, that gap is the whole problem.
06Fit
When this is worth doing, and when it is not
A good fit
- Several people depend on the same spreadsheet, and only one of them really understands it
- There are real consequences when a number is wrong: a mispriced quote, a missed obligation, a compliance gap
- The process is specific to how your business works, which is exactly why generic software has not fit
- Someone is spending hours a week on copying, reconciling, or chasing the current version
Probably not a fit
- What you need is a CRM, a help desk, or accounting software. Those are solved problems, and you should buy one rather than pay us to rebuild it
- The spreadsheet is a personal tool that one person uses and nobody else depends on. Leave it alone
- The underlying process is not settled yet. Software will freeze whatever it encodes, so it is worth deciding the process first
Send us the spreadsheet
The fastest way to find out whether there is a project here is to show us the file and tell us what it is supposed to do. A first conversation costs nothing and usually ends with a straight answer either way.