Software house: when to hire one (and when not to) — the non-technical founder’s guide

The first time I sat with a founder who’d been burnt by a software house, he showed me a repo with eleven thousand files, no README, no tests, and three commits named final-final.zip. The company that had delivered all that hadn’t answered a message in four months. He’d paid R$ 320,000. He had a system that worked. Almost. And nobody left who knew how to touch it.

The question he asked me, the same one in some variation that comes up in nearly every first meeting with non-technical founders, was this: “is it worth hiring a software house, or should I have done it differently?”

It is worth it, in most cases. But the question is poorly framed. A software house isn’t a choice against freelancers or against an in-house team. It’s one of the four real options a founder has to build software, and each one makes sense at specific moments. The mistake that cost the founder above R$ 320k wasn’t choosing a software house. It was choosing that software house for the wrong reasons.

This guide is about how to decide, and how to decide well.

What a software house actually is

A software house is a company that designs and builds custom software for other companies. The short version: a multidisciplinary team (product, design, engineering) that ships a working system from concept to deploy, without the buyer having to assemble an internal tech team.

In practice, what separates a software house from other ways of hiring engineering is the scope of the deliverable. A software house ships the product. A freelancer ships hours. An in-house team ships a team. The three cost money differently, demand different management, and produce different outcomes.

That “ships the product” line isn’t trivial. It means the software house owns the full package: spec, architecture decisions, code, QA, infrastructure, and the documentation that lets someone else continue the work later. When the delivery is good, the founder ends the project with a system running, a readable repo, and the real option to bring the team in-house later. When it’s bad, they end with eleven thousand files and no owner.

The four real options (and what each one is good at)

Before deciding to hire a software house, put the four real options you actually have on the table. Each solves a set of problems and creates another.

No-code. Bubble, Glide, Softr, Retool. Useful for validating an idea before paying real engineering. Cracks at the first customization the vendor’s roadmap didn’t anticipate. There’s a ceiling. Most founders stay six to twelve months longer than they should.

Freelancer or solo dev. Cheap on the hour, expensive in aggregate. Excellent for a small, well-defined slice (a connector, a script, an isolated feature). Bad for building a whole product: no code review, no redundancy, nobody to argue architecture trade-offs with. If the dev leaves, the system is orphaned.

In-house team (CTO + two or three engineers). The best path when software is the business and the company has the maturity to manage engineering. Expensive to assemble, slow to ramp, hard to manage if you don’t come from the field. If the company hasn’t reached the stage where software is real competitive advantage, it’s too early.

Software house. Ships the product and the documentation. Fast ramp-up (weeks, not months). Expensive per hour, but total cost is usually lower than the equivalent in-house team up through Series A, because you only pay the bandwidth you’re using. The risk is depending on a vendor for a central asset; the way to mitigate that lives in the contract and in who you hire, and both have their own sections below.

The rule that follows is practical: the more central the system is to the business and the more it’s going to change in the next twelve months, the more the balance tips toward an in-house team. The more the system is supporting and the more the founder needs to preserve focus elsewhere (sales, fundraising, regulation), the more it tips toward a software house. Freelancers only win on small slices. No-code only wins at validation.

The four-question framework

I run four questions with any founder before recommending hiring a software house, and before agreeing to work with a new client. If three of the four answers point the same direction, the call is easy. When they split, talk more before signing anything.

1. How clear is the spec?

This isn’t “do you have a requirements document.” It’s “can you explain, in two sentences, what problem you solve and for whom.” A software house is good at translating a clear idea into a system. It isn’t good (and it isn’t cheap) at helping you find out what the idea is.

If the answer is “I’m still validating the problem,” stop. Do discovery first, with yourself and the first customers. Buy a Bubble subscription if you have to. Come back to the software house when the spec is firm. Every hour a software house spends on product discovery costs you five times what the same hour costs spent on code.

2. How central is the system to the business?

There are systems that are the product (a fintech runs on its core banking layer) and systems that unlock operations (the internal panel that freed three people from the ops team). Both deserve software built well. But the kind of contract and the kind of transition you want at the end are different.

For central systems, plan to bring the team in-house from day one. The ideal software house here is the one that helps you hire your first engineers, transfers context, and steps out when you don’t need it anymore. For internal systems, a software house can be the long-term team. There’s nothing wrong with keeping a partner long-term to look after internal tools; it just needs to be agreed up front.

3. What’s your stage and runway?

Pre-seed and seed with a short runway: speed is everything. A software house ships fast because the team is already built. Spending three months hiring a CTO before you start building is three months you won’t get back.

Series A onward, with clear PMF and a long roadmap, the math changes. An in-house team gets cheaper in aggregate, generates an asset (talent that grows with the company), and creates continuity. That’s the natural transition point: software house to get the company off the ground, in-house team to scale it.

4. Who owns the code in eighteen months?

This is the question that separates the serious software houses from the rest. Ask explicitly, before you sign: the repo lives in my company’s GitHub from day one. The documentation is mine. When I hire my first engineers, your team sits with them, transfers context, and exits without trauma.

If the software house deflects or conditions its exit on a license, royalty, or mandatory support clause, run. The honest contracts are short on this point. The code is yours. It always was.

How to evaluate a software house without faking technical depth

This is where most non-technical founders get stuck. You don’t need to evaluate the stack they propose. You need to evaluate how they think.

Ask for the post-mortem on their worst project. A serious software house has one. A software house that says “we’ve never had a problem” is either lying or hasn’t been around long. What matters isn’t the mistake; it’s the level of detail and self-criticism in the answer.

Ask for references and call them with the camera off. Ex-clients who finished the project six-plus months ago are the best sample. Ask concrete things: was the budget honored? Who maintained the system after they stepped out? Would you hire them again? When a reference hesitates, you’re hearing the truth.

Ask to meet the people who will work on your project, not just sales. A serious software house lets you talk to the tech lead who will run the team. A bad one keeps a great account manager in front of you and hides the team that delivers.

Ask for a proposal with scope, not hours. “We’ll bill 1,200 hours at R$ 250” isn’t a proposal. That’s a blank check. “We’ll deliver module X for R$ Y, in Z weeks, with written acceptance criteria” is a proposal. A software house that only sells hours is telling you it doesn’t trust its own scope.

Look at the portfolio with skepticism. Pretty on Behance doesn’t mean good in production. Ask which of those projects is still running, which was discontinued, which was bought back by the client and moved to another vendor. The story after launch is what matters.

What it actually costs in Brazil

There’s a reasonable range and there are dangerous extremes. The averages below are for product projects of moderate complexity, with a small team (2–5 people allocated), in São Paulo, Rio, or other cities with mature tech markets.

Average hourly rate, BR market (2026): R$ 180 to R$ 350 per hour for senior teams, R$ 100 to R$ 180 for mixed teams with more juniors. Below R$ 100, be suspicious. Above R$ 400, you’re paying for a brand, and that may or may not be worth it.

MVP project (3 to 4 months): R$ 250k to R$ 600k is the band where honest projects usually happen. Below that, either the scope is tiny or someone’s cutting corners. Above, either the complexity is real (regulation, heavy integrations, applied ML) or you’re paying overhead.

Allocated squad, monthly (2 to 3 people, ongoing): R$ 80k to R$ 180k per month, depending on seniority.

Compare with the equivalent in-house team: a mid-level CTO and two senior engineers in São Paulo, with overhead, tools, and equipment, cost somewhere between R$ 90k and R$ 130k per month, and take three to six months to reach delivery cadence. A software house costs more per hour but starts shipping in week three.

Don’t make this call on a spreadsheet. Make it on runway. How long until you need a working product, and how much of your bandwidth do you want to burn managing people in that interval?

The contract conversation

Before signing, demand explicitly:

• Code ownership. The repo belongs to your company, on your company’s GitHub or GitLab, from the first commit. No licenses, no clauses limiting future use, no dependence on the vendor’s proprietary platform.
• A trauma-free exit clause. What happens when one side decides it’s over? Notice period, assisted transition, documented handoff. Written down.
• A communication SLA, not just an uptime SLA. How fast do they reply? Who’s your contact? What happens when the tech lead is on vacation?
• Acceptance criteria per delivery. What counts as “done” for each module. Concrete, measurable.
• A cap on scope creep. Scope changes generate an addendum, with a recalculated timeline and cost. They don’t snowball.

This is where most relationships go bad, and they go bad on something basic: nobody wrote down how the exit would work. Sign with a clean exit.

Warning signs mid-project

Some software house relationships start well and turn bad. The signs show up before the final delivery.

The weekly demo becomes monthly. A serious software house shows work every week. When the demo cadence drops, it’s because delivery cadence dropped, or because there’s something the team doesn’t want to show.

The tech lead changes without warning. People leave, that’s normal. What isn’t normal is finding out three sprints in that the person leading your project isn’t the one you interviewed. A solid software house communicates key staffing changes immediately.

Scope changes become taboo. You change something, they accept without renegotiating. Five changes later, the delivery is three months late and nobody can say why. Scope changes should generate healthy friction; when they don’t, somebody’s accumulating invisible debt.

Commit messages go generic. “fix bug,” “adjustments,” “WIP” as the message for a whole day’s work. It’s the code equivalent of “I’ll explain it to you later.”

When two of these signs cluster, ask for a frank conversation, with a written agenda, without sales in the room. Most souring relationships can be repaired if the conversation happens in month three. Almost none can be repaired in month eight.

The choice isn’t between vendors; it’s between futures

Every software-house decision is, in reality, a bet on what kind of company you want to be in eighteen months. A cheap, uncommitted software house ships a system that works until the next round and then jams. A serious one ships a system, a manual, and a clean transition to the team you’ll eventually hire.

The price gap between the two is smaller than it looks. The destination gap is the rest of the company.

If the choice between options is hard, go back to the four questions. How clear is the spec, how central is the system, what’s your stage, and who owns the code in eighteen months. Three of the four answers usually point the same way. When they do, go. When they don’t, wait another week and talk to one more reference before signing anything.

The right call isn’t the cheapest, and it isn’t the most sophisticated. It’s the one that lets you sleep knowing who is building what and why.