Our answer to "should we build this ourselves?" is usually no, which is an odd position for a software studio to take. But we would rather tell a company to buy a $200/month tool than take money to build a worse version of it.
There is a narrow set of conditions where building genuinely wins. Here is how to tell.
Buy, almost always, when
The problem is universal. Payroll, accounting, email, CRM, e-signature, helpdesk. Thousands of companies have the same need, which means mature products exist, competition has driven prices down, and the vendor spends more on that one product than you ever will. You cannot win this. Do not try.
Your process is not actually special. Everyone believes their workflow is unique. Most of the time it is the standard workflow with different vocabulary. If a good off-the-shelf tool requires you to change how you work, changing how you work is frequently the correct call and the cheaper one.
The tool is not close to your money. Software that supports the business but does not differentiate it should be bought. Nobody wins a market because of their expense reporting.
Build when one of these is true
The process is genuinely your edge. If how you route jobs, price work, or match supply to demand is the reason you beat competitors, that logic should not be constrained by someone else's product roadmap. This is the strongest reason to build and it is rarer than people think.
You are paying per seat for something you'd use at scale. Per-user pricing that made sense at fifteen people can become absurd at two hundred. When the annual license approaches the cost of building, the math flips — but be honest that building means maintaining, and maintenance never ends.
You are running the business out of spreadsheets nobody can replace. This is the most common real case we see. A company has grown around a set of interlocking spreadsheets that one or two people understand, that break constantly, and that no vendor product maps onto because the process evolved organically for a decade. No tool fits because the shape is genuinely yours.
Integration is the whole problem. Sometimes you have the right tools and the actual pain is that none of them talk to each other, and the connective work is where the hours go. What you need may not be a system but a layer between systems, which is a much smaller build than replacing anything.
The cost people forget
A bought tool has a price. A built tool has a price and a permanent liability.
Someone has to maintain it. When a dependency has a security issue, someone patches it. When the person who understood it leaves, someone relearns it. When the business changes shape, someone updates it. That obligation runs for as long as the business runs, and it is real cost even in years when nobody touches the code.
Our rule of thumb: assume ongoing cost of fifteen to twenty-five percent of the original build per year, indefinitely. If the build still beats buying with that included, build. If it only wins when you pretend maintenance is free, buy.
The middle path most people miss
Build vs. buy is a false binary. The most common right answer is buy the commodity parts, build the thin layer that makes them yours.
Keep the accounting package. Keep the payroll provider. Build the operational hub that pulls from both, applies your logic, and gives your team one place to work — so you own the part that is actually yours and rent the part that is not.
This is essentially what Flat OS is: not a replacement for the tools a staffing business runs on, but the layer that makes them behave like one system instead of nine.
How to decide in an afternoon
Write down the process. Not what you wish it were — what it is, including the exceptions and the manual steps.
Then find two or three products that claim to solve it and check honestly how much of your written process they cover. If it is ninety percent, buy it and change the other ten percent. If it is forty percent, and the missing sixty is the part that makes you money, you have your answer.
If you want a second opinion from people with no incentive to sell you a build, ask us. We tell people to buy more often than we tell them to build.