In-house vs agency vs freelancer for building software
The three ways to get software built, compared by a studio that sells one of them. Includes the cases where hiring us would be the wrong call, and how to spot them before you sign.
Insights
Almost everything written about how to commission software is written by someone who wants the answer to come out a particular way. We know, because we’re one of them. This section exists because the alternative, publishing nothing and letting a sales call carry the whole argument, is worse for you and worse for us.
Thirty-two pieces, in three groups. Choosing a partnercovers the decision before any code exists: in-house team, agency, or freelancer, how to run an offshore team so the handover doesn’t eat the savings, and how to leave an agency without losing your codebase. Cost & planningcovers the number everyone asks for first, why the published ranges for it disagree with each other by a factor of fifty, and what the “we’ll just plug in their API” line in a quote really commits you to. Engineering decisionscovers the calls we make on real projects. React Native or two native codebases, retrieval or a fine-tune, whether the thing needs to be an app at all, where background work runs when there’s no server to run it on, and when a spreadsheet has stopped being a spreadsheet.
These are for founders and operators who have to commission software they can’t personally write, and who have already noticed that every vendor comparison online concludes in favour of the vendor who wrote it. That suspicion is correct. Keep it.
One rule holds across all of them. Every figure is either linked to its source or labelled as our own estimate. Where our commercial interest points one way and the evidence points another, the article says so in the paragraph rather than in a footer. No client names appear on these pages, because we have not published any. No satisfaction percentages appear either, because we’ve never measured one. If a piece here helps you decide not to hire us, it did its job.
The decision before the build. Who writes the code, what that costs you in control, and what happens the first time it goes wrong.
The three ways to get software built, compared by a studio that sells one of them. Includes the cases where hiring us would be the wrong call, and how to spot them before you sign.
The signals that say hire, the more common ones that say wait, and what a first engineer really costs once burden, lead time and a possible mis-hire are counted. Written by the studio you would be replacing.
We are the offshore team on somebody else's org chart, so this is written from that side. The contract terms, rituals, and access rules that decide whether it works.
The handover checklist your outgoing agency would rather you did not have. Secure the accounts first, read what the contract actually assigns, then specify the audit as deliverables instead of adjectives.
Bus-factor risk nobody asks about until it bites. The five layers between your source code and a running system, the afternoon drill that tests all five, and why source code escrow is usually theatre.
A line-by-line method for reading a quote you did not write: the absent exclusions, the missing assumptions, the ownership clause nobody included. Ends with the five things a sceptical reader should push back on in our own proposals.
Acceptance for buyers who do not read code: criteria written before the work started, a staging URL you open yourself, the unhappy paths walked on purpose, and a reload to prove the data is really there. Including how to tell a defect from a change, and who pays for each.
The number everyone asks for first, taken apart into the decisions that actually set it.
Every MVP price range on the internet is unsourced, and they disagree by a factor of fifty. This takes the number apart into the decisions that drive it, so a quote stops being a mystery.
We sell fixed scope, so read this as a hostile witness. The buffer priced into every fixed bid, the change-order mechanics no competitor writes about, and the cases where our own quote is the wrong thing to buy.
A wish list defers decisions; a spec makes them, and only a made decision can be priced. The six answers that narrow a quote, the assumption a vendor writes in when each one is missing, and the honest case for buying a scoping week instead.
The finance posts tell you gross margin matters. This one does the request-path arithmetic that produces it, then explains why the average user is the wrong unit to forecast against.
Every result on this SERP either sells a connector layer or recycles the same unsourced maintenance percentage. This one walks the fourteen things that sit between a documented endpoint and a working integration, then prices the part that never finishes.
The five places a software budget actually breaks, ordered by how much money each one moves, and who absorbs it under fixed price against time and materials. Includes the buffer we price into our own bids and the cases where our estimate was the thing that was wrong.
A budget that stops at launch is the most common way a product dies. The line items nobody counts, why a framework two majors behind costs an order more than one on schedule, and a proportion of build cost you can defend in a board paper.
The $99 and $25 are trivial. What moves a plan is commission on whatever the stores classify as a digital good, a review queue you do not control, and platform deadlines that arrive every year whether or not you shipped.
The calls we make on real projects, with the tradeoffs left in rather than resolved in our favour.
A working document pipeline is four stages, not a platform purchase. What to build, where to put a human, and the confidence threshold that decides which records get read.
An agent that plans its own steps costs you determinism, testability and a predictable bill. Here is the test for whether your process actually needs one, and the workflow shape to build first if it does not.
Almost every team asking this question needs retrieval, not a fine-tune. The rule for telling them apart, what each costs to run, and the narrow cases where fine-tuning earns its keep.
Most of page one still describes the bridge React Native removed in 2025. Here is the current architecture, the parts that genuinely still need native code, and what the decision costs either way.
Rewrite-vs-refactor gets argued in the abstract because nobody publishes a way to measure the thing being argued about. Here is one: five signals, one working day, from a clean checkout.
Most of this SERP is a list of Next.js APIs presented as if order does not matter. It matters enormously. Diagnosis first, then the fix that survives the next deploy.
Every result on this SERP is an auth vendor concluding you should buy auth. Here is the same decision costed by someone with nothing to sell on it, including the third option the vendor posts leave out.
Every guide on this question answers “when” with a revenue threshold. This one answers it with four engineering triggers, then lays out the phased route that avoids a cutover weekend with your revenue riding on it.
The correct patterns are already circulating in fragments across a dozen post-incident blog posts. This assembles them into one architecture, with the specific failure mode each step exists to prevent attached underneath.
Page one is one vendor path and two GitHub threads from 2022. This compares the five mechanisms that actually exist, with the failure each one is there to prevent, and the case for not building a queue at all.
Every comparison on this SERP picks a winner and quotes one number per column. This one prices the three bills that actually differ: platform fee, engineering time, and who answers the page at 2am. With a decision rule by stage and the two cases where hiring us for it is wrong.
Every post on this question answers with engagement statistics. This one lists the eight device capabilities that actually force a native build, and says plainly what to do when none of them apply.
Every guide on this question lists pros and cons in the abstract and never costs the decision. This one does the arithmetic on the four things that actually decide it, then gives the migration path from shared to isolated that the rest of page one leaves out.
Most new products should be on Postgres, and the reasons are joins, transactions and the migration you will run either way. Written by a studio that defaults to Postgres, including the case where it chose a document store instead.
Every result on this SERP is a no-code vendor answering “how do I convert this”. This one answers “should I, and which parts”, with a one-day audit, four honest destinations, and the case for leaving the workbook alone.
The security question to ask before shipping anything with a model in it. Why instructions and data share one channel, where untrusted text really enters a product, and which mitigations buy the most, ranked honestly.
Every comparison grid scores the same API features and has no column for the two things that actually stick: how the editors work and how the content is modelled. Vendor prices read off their own published pages on one dated day, including where our own picks are the wrong answer.
Several of these pieces end in arithmetic or a decision rule you then have to redo against your own figures. Rather than leave you to it, we built the eight below. They run in your browser, they show their working, and none of them asks for an email.
Answer the questions and it writes the scope document, then names every gap a vendor will have to guess at.
The capability gates from the mobile app piece, as a checklist that returns a verdict and the requirement that forced it.
Thirty rules over what your site has to do, returning the platform your requirements force and what it costs to leave later.
The arithmetic from the MVP cost article, with the line items exposed and editable.
The request-path forecast from the LLM cost piece, run against your own usage shape and your own price.
What a manual process costs a year, against what an automation costs to own, and the month the two cross.
Twenty-three weighted items and four blockers that cap the score, measured against the days you have left.
Six weighted areas, with findings ranked by how reliably each one gets a deal repriced.
Describe the problem in a paragraph. Inside two working days you’ll have a scope, a price and a start date back, or the reason we’re not the right people for it.