The Brief Was Simple. The Market Solutions Were Not.

A UK-based electrical contractor came to us with a problem that is, frankly, extremely common. Their quoting process was a mess of spreadsheets, copied Word documents, and email threads that nobody could find. Jobs were being quoted inconsistently. Margins were being guessed at rather than calculated. And the director was spending three to four hours on every significant quote — manually pulling together labour rates, material costs, and compliance notes that should have been templated years ago.

The obvious suggestion, the one any salesperson would make, was to buy a SaaS product. There are dozens of field service management and quoting platforms on the market. We looked at them. The cheapest options capable of handling their workflow started at around £80 per user per month. With five people who needed access, that is £400 a month minimum, plus setup fees, training costs, and the near-certainty that 60% of the features would never be used.

We proposed something different: build it. Not a sprawling enterprise application — a focused, purpose-built quoting system that did exactly what this business needed and nothing else. The infrastructure cost is now under £20 a month. The system has been running for over a year. This is the full story of how we did it, what we used, and what we learned.

Why 'Buy' Is Not Always the Right Answer

There is a reflex in business technology decisions that treats off-the-shelf software as the safe, sensible option and custom builds as expensive vanity projects. That reflex is often correct. If your needs are generic, buying is faster, cheaper upfront, and someone else handles the maintenance.

But that logic breaks down in specific circumstances. When your process is genuinely differentiated — when the way you quote, price, and present work is part of your competitive advantage — forcing it into a generic tool means either compromising the process or spending enormous sums on configuration and workarounds.

This contractor had pricing logic that was specific to their business: tiered labour rates based on job type, a material markup structure tied to supplier agreements, and compliance documentation requirements that varied by installation category. No off-the-shelf quoting tool handled all three cleanly. The ones that got close required expensive add-ons or bespoke API integrations that would have cost as much as building from scratch anyway.

If you are trying to figure out whether your situation is genuinely build-worthy, our post on why your trades business may not need a £500/month SaaS subscription walks through the decision framework in detail. The short version: if you are paying for seats you do not use, features that do not fit, and workarounds that take more time than the tool saves, the economics of building deserve a serious look.

What the System Actually Needed to Do

Before writing a single line of code, we spent time documenting the current process end to end. This is not a step that can be skipped. Businesses routinely describe what they think their process is, and what they actually do are two different things. The gap between intention and reality is where most custom software projects go wrong.

We ran a structured discovery session with the director and the two estimators who handled most of the quoting work. We mapped every step from enquiry receipt to quote delivery, noting where decisions were made, where data was pulled from, where things got duplicated, and where things fell through the cracks.

The Requirements That Emerged

After that session, the genuine requirements were clear and surprisingly manageable:

That is it. No mobile app. No scheduling integration. No customer portal. No automated follow-up sequences. Those things might be worth building later. For now, the goal was to fix the quoting process and nothing else.

This discipline — scoping to actual need rather than aspirational capability — is the single biggest factor in keeping the cost down. Every feature you add is not just development time. It is ongoing infrastructure cost, ongoing maintenance, and ongoing complexity for the people using the system.

The Technology Stack — and Why We Chose It

We built the system on Firebase, Google's application development platform, with a React frontend. For a system of this kind — modest concurrent users, document-oriented data, need for real-time updates — Firebase is an extremely cost-efficient choice.

Firebase: What It Is and What It Costs

Firebase is a backend-as-a-service platform. It provides a real-time document database (Firestore), authentication, file storage, serverless functions, and hosting — all managed by Google, with no servers to provision or maintain.

The pricing model is what makes it attractive for systems at this scale. Firebase has a generous free tier (the Spark plan), and the paid tier (Blaze) charges based on actual usage. For a quoting system used by five people producing perhaps 80 to 120 quotes per month, the database reads, writes, and storage consumption are minimal. Monthly costs have consistently come in between £12 and £18.

Compare that to the alternative: a traditional VPS running a Node or PHP backend with a PostgreSQL database would cost at least £20 to £40 per month before you have written anything, and requires ongoing server management. For a small internal tool, that overhead is not justified.

React: Keeping the Frontend Maintainable

We used React for the frontend, hosted on Firebase Hosting (which serves static files and costs essentially nothing at this traffic level). React was the right choice here for a straightforward reason: the developers at Daybrain know it well, component libraries like shadcn/ui make building clean interfaces fast, and the resulting codebase is readable by any competent frontend developer if the client ever needs to bring maintenance in-house.

We are deliberately not precious about technology choices. The best stack for a project is the one that the team building it knows well, that has strong community support, and that will not become a liability in three years. React ticks those boxes.

PDF Generation

Generating branded PDFs is one of those features that sounds simple and is frequently anything but. We used a Firebase Cloud Function triggered on quote finalisation, which calls a headless browser library to render the quote template as HTML and convert it to PDF. The resulting document is stored in Firebase Storage and a download link is emailed to the user.

The per-invocation cost of Cloud Functions at this volume is negligible — a few pence per month at most.

Authentication

Firebase Authentication handles user login with email and password. There is no per-seat fee for Firebase Auth. Five users, fifty users, five hundred users — the authentication cost does not change meaningfully at this scale. This is one of the places where building beats buying most obviously: SaaS tools charge per seat because that is their business model, not because the underlying cost scales that way.

The Build: Timeline and Cost

The build took six weeks from discovery to handover. That includes the initial scoping session, design, development, testing with the actual users, a round of revisions, and a handover session to make sure the director could manage the materials library and labour rates without needing to call us.

A Realistic Cost Breakdown

We are being deliberately transparent here because vague claims about 'affordable custom software' are not useful to anyone trying to make a real decision.

The build cost in professional fees was in the range of £8,000 to £10,000. That covers discovery, design, development, testing, and handover. It is not cheap in absolute terms. But against the alternative — £400 per month for a SaaS tool that fits imperfectly — the payback period is under two years, and after that the cost advantage compounds indefinitely.

More importantly, the director estimates he has recovered around eight hours per week across the team from the previous quoting process. Quotes that took three to four hours now take forty minutes. At any reasonable internal cost rate for senior time, that productivity recovery alone pays for the build within the first year.

If you want a rigorous way to calculate the ROI of a project like this before committing, our post on calculating automation ROI gives you a framework that works for technology investments of any size.

Ongoing Infrastructure Cost

After handover:

Total ongoing infrastructure: under £20 per month. There is no per-seat fee, no annual licence renewal, no price increase when a new salesperson joins the team.

The Framework: When to Build vs Buy

This project is a useful illustration of a decision framework we apply at Daybrain Consult when evaluating technology options for clients. It is not a formula — every situation has context that a formula cannot capture — but it gives you a structured way to think through the question.

The Build vs Buy Assessment

Work through these seven questions honestly. If you find yourself rationalising answers to reach a conclusion you have already decided on, that is a signal worth noticing.

1. How differentiated is your process?
If your quoting, pricing, or delivery process is genuinely specific to your business — if it reflects accumulated knowledge and competitive positioning — a generic tool will struggle to represent it cleanly. The more differentiated your process, the stronger the case for building.

2. What is the realistic per-seat cost over three years?
Do not evaluate SaaS on monthly cost alone. Calculate the three-year total including all users, any usage-based overages, implementation fees, and the cost of any integrations you need. Compare that to a realistic build cost plus ongoing infrastructure.

3. How much of the SaaS product would you actually use?
If the honest answer is 30 to 40%, you are paying for complexity that adds friction rather than reducing it. Users find workarounds. The tool gets used inconsistently. The data quality degrades. A focused custom build used fully is almost always more valuable than a sprawling platform used partially.

4. What is the integration burden?
If the off-the-shelf tool needs to integrate with your existing systems — accounting software, CRM, job management — and those integrations are not native and well-maintained, factor in the real cost of building and maintaining them. Integration debt is one of the most underestimated costs in technology decisions.

5. How stable are your requirements?
Custom builds shine when your requirements are well understood and relatively stable. If your process is actively evolving, a configurable SaaS tool may be more appropriate — it is easier to adjust configuration than to re-engineer code. Build when you know what you need. Buy when you are still figuring it out.

6. Do you have access to competent builders?
This one is obvious but often skipped. A custom build is only viable if you have access to developers who can build it well and maintain it afterwards. 'My nephew knows a bit of coding' is not a viable plan. If you do not have a trusted technical partner, the risk profile of building changes significantly.

7. What is the exit cost of getting it wrong?
If you buy a SaaS tool and it does not work out, you cancel the subscription and move on. If you build and the build fails, you have spent significant money and time and still have the original problem. Honest assessment of technical risk matters.

How This Project Scored

For this contractor: highly differentiated process, three-year SaaS cost of around £15,000 for an imperfect fit, realistic custom build cost of £8,000–10,000, stable and well-understood requirements, and a trusted technical partner in place. The case for building was strong on every dimension.

That combination does not always align. We have had conversations with clients where we have actively recommended buying rather than building, because their process was generic, their requirements were evolving, or the available SaaS solution was genuinely good enough. The goal is the right answer, not a particular type of answer.

What the Users Said

This section matters more than most case studies acknowledge. A system that works technically but that users actively dislike or work around is not a successful system.

We built in a feedback loop — informal check-ins with the estimators at two weeks, six weeks, and three months post-launch. Here is what they reported honestly.

What Worked Immediately

The materials library was the immediate win. Having current prices in one place, accessible by everyone, eliminated the version-control chaos of spreadsheets. Quotes produced by different estimators were now consistent in how they priced materials, which had not been true before.

The PDF output was the other immediate win. The director had previously spent time formatting Word documents to make them look professional. The system generates a clean, branded PDF in seconds. That alone removed friction from every single quote.

What Needed Adjustment

The labour rate configuration was initially too rigid. We had built it with three rate categories, but the estimators identified within the first two weeks that they needed a fourth for a specific type of work that sat between two existing categories. We updated it within a day. This is one of the advantages of owning the codebase — changes are made in hours, not submitted to a SaaS vendor's feature request backlog.

The status tracking also needed a small addition: a 'revised' status for quotes that had been sent, revised following client feedback, and re-sent. The original design had not anticipated that step, because it had not come up in discovery. It was a fifteen-minute change.

What They Would Add Next

After a year of use, the team has a list of enhancements they want: automated follow-up reminders for quotes that have been open for more than two weeks, a simple dashboard showing pipeline value by quote status, and integration with their accounting software to push accepted quotes through as jobs without re-keying the data.

These are all buildable. The architecture supports them. And because the infrastructure cost is fixed at under £20 a month regardless, adding features does not trigger a pricing tier increase — only the development time to build them.

The Spreadsheet Problem Underneath All of This

It is worth stepping back to name the underlying dynamic that makes projects like this necessary. Almost every quoting system we have seen in small and mid-sized businesses started as a spreadsheet. The spreadsheet was sensible at the time — fast to build, easy to share, flexible enough to accommodate the process as it existed then.

The problem is that spreadsheets do not evolve gracefully. They accumulate complexity. Different versions proliferate. Formulas break silently. New people join and create their own versions. The quoting process becomes the spreadsheet's process rather than the business's process — shaped by what the spreadsheet can represent rather than what actually needs to happen.

By the time this contractor came to us, they had four different quote templates in use across the team, with no clarity on which was current. Margin calculations in two of them were wrong — a formula error that had gone unnoticed for at least six months. If you recognise that pattern, our post on the signs your business has outgrown its spreadsheets is worth reading before you decide how to respond to it.

The fix is not always a custom build. Sometimes it is a well-configured SaaS tool. Sometimes it is a more disciplined spreadsheet with better version control. But it is always some kind of intentional decision — not just continuing with the inherited mess and hoping it holds together.

Scaling and Maintenance Considerations

A common objection to custom builds is the maintenance burden. Who fixes it when something breaks? Who updates it when requirements change? These are legitimate questions, and they deserve honest answers.

What Firebase Manages for You

One of the reasons we chose Firebase for this type of project is that it dramatically reduces the surface area of things that can go wrong at the infrastructure level. Google manages the database, the authentication service, the file storage, and the hosting. There are no servers to patch, no database backups to configure, no SSL certificates to renew manually.

In over a year of operation, this system has had zero infrastructure-related incidents. That is not luck — it is a function of building on managed infrastructure that has Google's reliability guarantees behind it.

Application Maintenance

The application code does require occasional attention. Dependencies need updating. Edge cases surface over time. New requirements emerge. The client has a lightweight support arrangement that covers reactive fixes and small enhancements on a time-and-materials basis.

In the first year, that has amounted to perhaps six to eight hours of developer time total. At a reasonable hourly rate, that is a small fraction of the infrastructure savings compared to the SaaS alternative.

What Happens if Daybrain Is Not Available

We handle this question directly with every client who builds with us. The codebase is version-controlled in a repository the client owns. The documentation covers the architecture, the data structure, and the deployment process. A competent developer who has never worked with us before could pick this up and maintain it.

That is not just a reassurance — it is a design constraint we impose on ourselves during the build. If the code would only make sense to the person who wrote it, that is a problem we have created for the client.

What This Means for Your Business

If you are running a quoting process — or any operational process — on a combination of spreadsheets, email, and institutional memory, the question is not really 'should we fix this?' The answer to that is obviously yes. The question is how, and at what cost.

The instinct to buy a SaaS product is understandable. It feels lower risk, faster, and more professionally defensible. But 'lower risk' is relative. Paying £400 per month for a tool that your team uses inconsistently and that forces workarounds into your process is not a risk-free choice — it is just a more familiar kind of failure.

Bespoke software has historically been associated with large budgets and uncertain outcomes. Both of those associations are less true than they used to be. Modern cloud infrastructure, mature component libraries, and experienced development teams mean that focused, well-scoped custom builds are within reach for businesses that would never have considered them ten years ago.

The key word is focused. The system we built for this contractor does eight things well. It does not try to do thirty things adequately. That discipline is what keeps the cost down, the adoption high, and the maintenance burden low.

If you are evaluating a technology decision along these lines — buy versus build, which stack, how to scope it — that is exactly the kind of work Daybrain Consult does. Not a discovery workshop that produces a deck. A structured engagement that ends with a clear recommendation and a plan you can act on. If you want to know what that looks like in practice, this post walks through a real consulting day from start to finish.

The Takeaway

A full quoting system — customer database, materials library, configurable labour rates, quote builder with margin calculation, branded PDF output, status tracking, and basic reporting — running for under £20 a month on Firebase is not a theoretical possibility. It is a thing that exists and has been running in production for over a year.

The infrastructure cost is low because the architecture was chosen deliberately. The build cost was justified because the three-year comparison against the SaaS alternative made it clear. The system works because the scope was honest — built for what the business actually needed, not for what a vendor's feature matrix suggested it should want.

The next time you are about to sign up for a per-seat SaaS subscription, do the three-year maths first. Factor in the seats you will pay for but not fully use. Factor in the integrations you will need to build anyway. Factor in the features you will work around rather than use. Then ask whether a focused, purpose-built system might actually be the cheaper, better-fitting option.

It will not always be. But it is the right question to ask — and most businesses never ask it.