We get asked this question a lot. Sometimes it comes from other founders. Sometimes from clients who are mid-conversation about their own stack and want to know whether we practice what we preach. Occasionally it comes from developers who are curious about the choices behind what we ship.

So here it is — the unvarnished version. What we use, why we chose it, what it costs, and where the trade-offs are. No sponsored mentions, no affiliate links, no pretending everything is perfect.

This is not a list post dressed up as strategy. It is a working account of how a small, technically serious consultancy keeps its operations lean without cutting corners on quality. If you are a business owner, operations director, or senior leader thinking about your own technology decisions, there is something useful here for you — even if your business looks nothing like ours.

Why the Stack Question Matters

Most businesses do not think carefully enough about their internal tools until those tools start costing them real money or causing real pain. By that point, the cost of switching is high, the institutional knowledge is buried in a dozen different systems, and the options feel overwhelming.

The better time to think about this is before you feel the pain. And the best way to think about it is with concrete examples — not abstract principles about scalability or vendor lock-in, but actual decisions made by actual teams with actual constraints.

We have written before about the signs that your business has outgrown its current tooling. What we have not written about is what comes after that recognition — which is the hard work of choosing something better and making it stick.

Our own stack reflects choices made under real constraints: a small team, a need to move quickly, strong opinions about data ownership, and a preference for paying for infrastructure rather than per-seat SaaS wherever possible. If those priorities sound familiar, read on.

The Core Infrastructure: Firebase

Firebase is the foundation of most of what we build and almost everything we run internally. That is a deliberate choice, and not an obvious one for a consultancy that works across industries.

Firebase is Google's application development platform. It gives you a real-time database (Firestore), authentication, cloud functions, file storage, and hosting — all under one roof, with a generous free tier and a pay-as-you-go model that scales predictably. For a small team building bespoke tools, it removes a significant amount of infrastructure complexity.

What We Actually Use It For

Internally, we use Firebase for our project tracking, client onboarding flows, and the custom tools we have built for our own operations. Externally, it is the backend for most of what we ship under the Daybrain Digital banner and for the bespoke client applications we build through Daybrain Consult.

The key advantage is cost structure. A well-architected Firebase application is cheap to run. We have covered this in detail in a real case study — a custom quoting system built for a UK contractor running for under £20 a month — and the numbers hold up across most of the applications we build. When you are not paying per seat, and you have designed your data reads sensibly, Firebase is remarkably affordable at small-to-medium scale.

The Honest Trade-offs

Firebase is not the right tool for everything. Complex relational data with lots of joins belongs in a relational database, and trying to force it into Firestore's document model creates problems that are not worth solving. If your application is primarily about querying structured data in sophisticated ways — reporting tools, financial systems, anything with heavy aggregations — Firebase is the wrong starting point.

There is also the vendor dependency question. You are running on Google infrastructure, and while Firebase has been stable for years, it is a managed platform. We accept that trade-off because the productivity gains are real and the cost structure is excellent. But we do not pretend the trade-off does not exist.

For our use cases — operational tools, client-facing applications, real-time dashboards, automation triggers — Firebase earns its place every time.

AI Tooling: Claude API and Where It Fits

There is a lot of noise about AI at the moment, most of it either breathlessly optimistic or reflexively dismissive. We have written about what AI actually means for small business owners, and the short version is: it is a tool, not a strategy. It does specific things well. It does other things badly. The value is in knowing which is which.

We use Claude from Anthropic, via the API, as a core part of our internal workflow. We also build with it for clients where it makes sense. Here is how that breaks down.

Internal Use: Writing, Thinking, and Drafting

Claude handles a significant portion of our first-draft work — not because we want AI to write for us, but because having a capable first draft changes the quality of the editing process. Starting from something concrete, even if it is imperfect, is faster than starting from nothing. The output always goes through a human before it goes anywhere.

We also use Claude for what we call structured thinking — feeding in a problem, a set of constraints, and a desired output format, and using the response as a thinking tool rather than a final answer. This is different from asking it to write something. It is closer to talking through a problem with a colleague who reads quickly and has broad context.

Prompt engineering matters here. Vague inputs produce vague outputs. The quality of what you get from a language model is almost entirely determined by the quality of what you put in. This is a skill, and it is one we invest in deliberately.

Client-Facing Integrations

We build Claude integrations into client products where there is a genuine use case. This means things like intelligent form processing, document summarisation, structured data extraction from unstructured inputs, and conversational interfaces for internal tools.

What we do not do is bolt AI onto something because the client thinks they should have AI. If the use case is not clear, the integration will not be useful, and it will add cost and complexity for no return. Every AI integration we ship has a specific job to do and a metric for whether it is doing it.

Cost and Practicalities

The Claude API is priced per token — you pay for what you use, not a flat subscription. For most of our internal use, the monthly cost is modest. For client integrations, usage costs need to be modelled carefully before build, particularly if you expect high volumes.

One practical note: the API gives you much more control than the consumer product. You can set system prompts, control temperature, structure outputs as JSON, chain calls, and integrate responses directly into your application logic. If you are building anything serious with AI, the API is where to start — not the chat interface.

Communication and Collaboration

We are deliberately minimal here. The more tools you add to your communication stack, the more time your team spends managing the stack rather than doing work.

Slack

Slack for internal communication. We use it with discipline — channels have clear purposes, notifications are turned off by default, and we do not use it as a replacement for documentation. Slack is good for quick back-and-forth and staying loosely coordinated. It is terrible for decisions that need to be recorded or information that needs to be findable later.

If something discussed in Slack needs to persist, it goes somewhere else. This sounds obvious. In practice, most teams do not do it.

Notion

Notion handles our documentation, internal wikis, and project-level notes. It is a flexible tool that rewards deliberate structure and punishes the lack of it. We have built a fairly opinionated internal structure over time — there is a right place for things, and the team knows what it is.

We use Notion databases for tracking work across clients and projects. They are not as powerful as a proper project management tool, but they are good enough for our size, and the benefit is that everything lives in one place alongside the documentation that gives it context.

Email

Gmail, via Google Workspace. Nothing interesting to say here. It is email. It works.

Development Tooling

This section is more technical, but it is relevant to any business leader who wants to understand how their software gets built — either by us or by anyone else.

VS Code and Cursor

The primary coding environment is VS Code, with Cursor increasingly used for AI-assisted development work. Cursor is a code editor built on top of VS Code that integrates language model assistance directly into the development workflow. For certain tasks — writing boilerplate, navigating unfamiliar codebases, generating test cases — it is genuinely useful. For others, it gets in the way.

The practical implication for clients is that AI-assisted development does change how quickly certain types of work can be done. Boilerplate code that would have taken a day can take an hour. But this does not mean AI writes the application — it means the developer writes more of the interesting parts and less of the repetitive parts. Quality and architecture are still human decisions.

GitHub

Version control and code review on GitHub. This is industry standard for good reasons. Every project has a repository, every change goes through a pull request process, and the history of every decision is there if you need it. For client projects, we give clients access to their own repository as a matter of course. The code belongs to them.

Deployment

Firebase Hosting handles most of our deployment needs for web applications. For more complex backend requirements, we use Google Cloud Run — containerised services that scale to zero when not in use, which keeps costs low without sacrificing capability.

The pattern we follow consistently is: use managed services wherever the cost is justified, avoid managing infrastructure that does not give you a competitive advantage. A small team maintaining its own servers is almost never a good use of time.

Financial and Administrative Tools

These are the tools nobody talks about in tech stack posts because they are unglamorous. They matter.

Xero

Accounting on Xero. The UK small business accounting market is dominated by Xero and QuickBooks, and the choice between them is largely personal. Xero has good API access, which matters to us because we can pull data into our own tools when we need to. The bank feeds work reliably. The invoicing is clean. It does what it needs to do.

Stripe

Payment processing via Stripe. Again, an industry standard. The API is excellent, the documentation is among the best in the business, and the integration with most other tools is straightforward. We use it for our own billing and build it into client applications that need payment flows.

What We Do Not Use

We do not use a CRM. For a consultancy of our current size, a well-maintained Notion database does the job without adding another tool and another monthly line item. This will change when it needs to change.

We do not use project management tools like Jira or Asana. The overhead of maintaining those systems at small scale typically exceeds the benefit. Notion boards handle what we need.

We actively avoid tools that charge per seat for functionality we use lightly. The per-seat model made sense when software was expensive to distribute. In the current environment, a small team can end up paying enterprise-level prices for tools that individual contributors use twice a month.

A Framework for Making Stack Decisions

The choices we have made are not universally right. They are right for our size, our team, our type of work, and our priorities. What we can offer is the framework we use when evaluating tools — for ourselves and for clients.

The Five Questions We Ask Before Adding a Tool

1. What is the actual job this tool is doing?
Not the category (project management, CRM, analytics) but the specific function. If you cannot state it in one sentence, you probably do not have a clear enough use case.

2. What is the total cost of ownership?
Licence cost is one number. But there is also setup time, training time, ongoing maintenance, and the cost of the data migration you will need when you eventually leave. Per-seat tools look cheap at five users and expensive at fifty.

3. Who owns the data?
This question is underasked. If you put five years of client records into a SaaS platform and that platform changes its pricing model, gets acquired, or shuts down, what happens? Some tools make data export easy. Others make it deliberately difficult. Know this before you commit.

4. Does this replace something, or add to something?
Every new tool adds cognitive load, training overhead, and integration complexity. If a new tool is not replacing something you already use, the case for adding it needs to be very strong.

5. Will this still make sense at twice our current scale?
Not ten times — twice. Most small businesses do not need to plan for ten times the scale. But a tool that becomes expensive or inadequate at twice your current size is going to cause pain sooner than you think.

A Worked Example: How We Evaluated Our Documentation Tool

When we needed a documentation and knowledge management system, the options were Notion, Confluence, GitBook, a custom-built internal wiki, and a shared Google Drive with strong conventions.

We ruled out Confluence immediately — it is built for large engineering teams and carries the complexity to match. We ruled out GitBook because the pricing model at the time did not suit our needs. We considered Google Drive seriously: the cost is effectively zero and everyone knows how to use it.

We chose Notion because the database functionality let us combine documentation with lightweight project tracking in a single tool — replacing two separate systems. The per-seat cost is modest. Data export is possible, if not frictionless. The structure is flexible enough to evolve with us.

That decision took about a week of deliberate evaluation. It is now a system that works well enough that we do not think about it. That is the goal: infrastructure that disappears into the background so the team can focus on the work.

What This Costs in Total

We are not going to publish our exact spend, but we can give you a realistic picture of the category totals, because this question comes up in almost every consulting engagement we take on.

For a small professional services firm or technical consultancy with five to fifteen people, a lean and well-chosen stack should cost somewhere between £500 and £1,500 per month in software licences and infrastructure. If you are spending significantly more than that and cannot point to specific, high-value tools that justify the premium, there is almost certainly room to consolidate.

The places most small businesses overspend are predictable:

The fix for all of these is a quarterly stack audit. One hour, once a quarter, reviewing every tool against the five questions above. It is not glamorous work. It saves real money and reduces real complexity.

What We Would Do Differently

In the interest of genuine usefulness, here are the calls we have made that we would revisit.

We delayed building internal tooling longer than we should have. For the first year, we managed more with spreadsheets than was sensible, partly out of caution and partly because we were busy. We eventually built what we needed — but the productivity gains were available earlier.

We should have standardised our development environment documentation earlier. Onboarding a new developer into a project involves setup steps that should be documented and mostly are, but the consistency across projects is not as high as it should be.

We have occasionally added tools reactively — in response to a specific immediate need — without adequately considering whether the same need could be met by a tool we already had. The discipline required is to solve problems with what you have before reaching for something new. We are better at this now than we were.

The Honest Recommendation for Business Owners

If you are a business owner or operations director reading this and thinking about your own stack, the most useful thing we can tell you is this: the quality of your tooling decisions compounds over time. A good decision made today is still paying dividends in three years. A bad one is still causing friction in three years.

Most businesses do not make deliberate tooling decisions. They accumulate tools in response to immediate problems, and over time those tools harden into infrastructure that is expensive and painful to change. This is one of the core things we look at when working with clients through Daybrain Consult — not because technology is the only lever, but because fixing a bad stack often unlocks improvements that are not available any other way.

The stack decisions we have made — Firebase as infrastructure, Claude API for AI capability, Notion for knowledge management, minimal per-seat tooling — reflect a set of priorities that might not match yours. But the framework behind those decisions is transferable. Know what job each tool is doing. Know the real cost. Know who owns the data. Replace before you add. Plan for twice your current scale.

If you apply those five questions consistently, you will make better decisions than most businesses do. And if you want to work through those questions with people who have done this across a lot of different industries and contexts, that is exactly the kind of work we do.

The Takeaway

Running a lean technical operation is not about using the cheapest tools. It is about using the right tools for your actual situation and being ruthlessly honest about what is earning its place. For us, that means Firebase for infrastructure, Claude API for AI capability, and a consistent preference for infrastructure costs over per-seat licences.

The stack is not the point. The work is the point. Good tooling decisions make the work easier, cheaper, and more reliable. Bad ones get in the way of it — and the cost accumulates slowly enough that most businesses do not notice until it is already significant.

Do an audit. Ask the five questions. Cut what does not earn its place. That is the whole prescription.