What Is a Software House? How Development Agencies Work

• A software house builds custom software for a client, which a US buyer would call a software development company or a dev shop.
• Unlike a staffing agency, a software house assembles the team and takes responsibility for design, development, project management, and release.
• A typical engagement starts with a free call and about two weeks of discovery; development can begin around week four.
• I steer most first-time buyers toward time-and-materials, because products change once people start using them.
• At handover, you should get everything another team needs to take over, starting with the source code.

The clearest US definition comes from the government's industry codes. Under NAICS code 541511, the US Census Bureau describes custom programming firms as "primarily engaged in writing, modifying, testing, and supporting software to meet the needs of a particular customer." NAICS puts companies that publish their own packaged software in a separate industry, so a software house is a different kind of business from the company behind your accounting tool.

The term is older and more British than most Americans expect. Collins English Dictionary labels it as a British term. The BCS, the UK's Chartered Institute for IT, dates the UK's first software house to February 1959, when Dina St Johnston founded Vaughan Programming Services. Collins defines it as a firm that produces "computer software packages," but in Poland today, the word almost always means custom development for clients.

Some explainers online also confuse a software house with a managed IT services provider, which runs and supports the systems you already have, whereas a software house builds new software that becomes yours.

US buyers rarely use the term, so on a first call I explain it like this:

"Software house" is a term used in Europe for a company that designs and builds software for other businesses. In the US, "software development company" or "dev shop" usually gets the idea across more easily.

The useful distinction is how much responsibility you're handing over. With staff augmentation, you bring developers into a team that you manage. A software house can put a team together and handle the design, development, project management and release.

At Milo, we help founders build products when they don't have their own engineering team. We work through the design, build the software, help launch it, and stay involved afterward.

For a US audience, I'd use "software development company" and explain "software house" once. Then I'd get into what they need to build.

Plenty of people search for it as a single word, "softwarehouse," and they mean the same thing. Searching the term from the US also turns up a namesake. Software House is a Johnson Controls product brand unrelated to custom development, and its C●CURE 9000 system appears in a CISA security advisory.

A full-service software house can take a product from an idea to software people use every day. In practice, that work usually covers these stages:

• discovery, where you agree on what to build and how
• user experience (UX) and interface design
• frontend, backend, and mobile development
• quality assurance (QA), meaning testing before your users see the software
• deployment, plus maintenance and support after launch

At Milo, that work runs on Node.js, React, Next.js, Django, Flutter, and Qt/C++, which lets one team cover a web dashboard and its mobile app, plus the backend for both, without you having to hire a separate vendor for each. For web products, I've written about choosing web application development services.

Timelines vary with what you're building, but the shape repeats whether it's a full product or an MVP (minimum viable product, the smallest version real users can try). Two terms come up a lot: a sprint is a short, fixed block of work that ends with something you can review, and the backlog is the ranked list of tasks waiting to be built.

We start with a free call to understand what the client wants to build, what they already have, and where they need help. If there's a fit and we agree to work together, we move into kickoff and discovery.

The delivery team joins the kickoff. A typical starting team has four or five people, covering backend, frontend, infrastructure and project management, with QA and design involved as needed. For a smaller MVP, that might mean two developers with part-time help from the other roles.

Discovery is where we work out what we're actually going to build. For a straightforward product, it can take about two weeks and produce an agreed scope, an infrastructure plan and a backlog for the first development sprint. More complicated products need more time. At Stepwise, an emissions platform for offshore oil and gas operators, discovery involved 10 workshops over roughly 2 months before production development began.

The client has access to the work from the start. We use Jira for tasks, Slack for day-to-day communication, and Figma for design feedback. The code is pushed to a Git repository owned by the client.

Development then runs in sprints, with short daily check-ins, a weekly call and regular demos. Those demos give the client a chance to try the software and raise questions while there's still time to make changes.

As a rough guide, week one covers kickoff and access. Weeks two and three are for discovery, wireframes, and the delivery plan. Development can start around week four, with a first version the client can see and try by the end of the first build sprint. The actual schedule depends on the product.

If you've never bought custom software, one thing will probably surprise you:

How much of their own time the project still takes. We can handle development, but we still need them to answer questions, review the work, and make decisions.

So before kickoff, name one person on your side who can answer questions and make product calls within a day or two, because the team keeps working while it waits for answers.

What did that look like on a real project?

I've mentioned Stepwise before when writing about how to choose an MVP development company, and it's also the clearest example I have of a whole engagement, from discovery through to a handover to the client's own team.

Stepwise is an emissions and energy-management platform for offshore drilling operations. It helps teams plan reductions in fuel use and emissions, then compare those plans with what is actually happening on the rig.

We started with ten discovery workshops over roughly two months. The first commit in the repository is dated 21 February 2022. The work covered replacing spreadsheet-based planning, connecting rig-monitoring data, and turning equipment readings into usable fuel-consumption and emissions figures.

One decision that mattered was supporting manual data entry and a public API alongside the automatic data feed. Getting permission to access a rig's data could take time, and some rigs used different equipment. Those alternatives let clients start using the platform while access to the automatic feed was still being approved.

We also made rig configuration something Stepwise's staff could handle themselves. They could map the incoming measurements and set up calculations through an admin interface. Once that framework was in place, another rig could usually be configured in a few hours, without asking us to change the code or deploy the application.

The platform brought planning and measured results together. It compared historical baselines, planned reductions, and actual measurements each hour, so teams could see how an emissions-reduction plan was performing while the operation was still underway.

Stepwise's own team took over the platform, and one of our engineers stayed involved as the last person from our side until October 2026.

The manual-entry fallback and self-service rig setup both came from discovery conversations about how rigs actually operate, which is why I think discovery earns its time even when you're keen to start coding. The Stepwise project page has more on the platform.

What should you own when the project ends?

First-time buyers often forget to ask what they'll walk away with. I think it's the most important question in the contract:

They should have everything another team needs to take over: source code, design files, documentation, deployment instructions, and access to the infrastructure. The thing I've seen vendors hold back is the source code itself.

Under US law, work from an outside contractor doesn't automatically belong to you. The US Copyright Office's Circular 30 on works made for hire explains that a commissioned work counts as "made for hire" only if it fits one of nine listed categories and both parties sign a written agreement saying so. Make sure your contract also includes a clear assignment of intellectual property (IP) to your company. Have a lawyer read it before you sign.

Most software houses offer the same three commercial models.

US federal contracting rules define the first two plainly. The Federal Acquisition Regulation on fixed-price contracts defines "a price that is not subject to any adjustment" as one that "places upon the contractor maximum risk and full responsibility" for costs. Its time-and-materials rules are meant for work where nobody can "estimate the extent or duration of the work," and that describes most new products, which is why I give first-time buyers this advice:

For most first-time buyers, I steer toward time and materials. It works best for us and the client, especially when the client has a budget and knows what they want to achieve but doesn't have that budget set in stone. It lets us adjust as we learn, without arguing over every change.

We do fixed-price projects too. From experience, though, they are often problematic for both sides. Extra costs are hard to avoid. A common example is when the client tests the front end and comes up with new functionality they hadn't thought of before. That is completely natural, and we're willing to adapt as far as our overall planning allows. But on a fixed price, every change becomes a negotiation, and that strains the relationship.

A dedicated team usually makes sense later, once you have a live product with steady work, and I cover it in the Dedicated Software Teams Guide.

For market context, Clutch's software development pricing guide, based on verified client reviews and updated in September 2026, puts the most common hourly rate in the $25-$49 range and the average project cost at about $132,480. Its usual project timeline is about 13 months. Treat those figures as market averages rather than a quote. For how pricing works in more depth, see our Software Development Pricing Guide.

To tell these options apart, ask who answers for delivering the product.

If you're considering an in-house hire instead, the US Bureau of Labor Statistics reports a median pay of $135,980 per year for a US software developer as of May 2025. For the wider outsourcing picture, see our Software Outsourcing Services Guide.

Poland has a large technical workforce, and much of its services industry sells abroad. Eurostat's ICT specialist data show 778,800 ICT specialists working in Poland in 2025, accounting for 4.5% of total employment. Across the whole EU, the figure was 10.45 million, or 5.0% of employment, according to Eurostat's May 2026 news release.

According to the National Bank of Poland, as reported by the Polish Investment and Trade Agency, exports of IT and telecommunications services brought Poland USD 13.4 billion in 2022, up more than 15% on 2021. I make the fuller case for hiring in Europe, including time zones and EU law, in our Software Development Companies in Europe Guide.

Sometimes the most useful thing I can tell a founder on a first call is that they shouldn't hire us, or anyone like us:

The clearest reason not to hire a software house is that a well-established product already solves your problem. Before discussing a custom build, I'd ask what you've looked at and what those products are missing. If you can't identify a feature or capability that matters to your business and isn't already available, I'd recommend using an existing product.

Custom software means paying to build, maintain, and support it. There needs to be a clear reason to take on that work.

Even when you find a gap, it might be possible to address it through configuration, an integration or an extension. I'd explore those options before recommending that you build an entire system from scratch.

A software house is also a poor fit for a small, one-off fix. A freelancer can usually turn that around faster. The same goes when nobody in your company can own product decisions, because an outside team needs someone on the client side to decide what gets built. If a software house does fit your situation, I cover how to compare vendors in our Development Outsourcing Company Guide.

What does a software house do?

A software house designs and builds custom software for other companies. You explain the problem and make product decisions, and the software house supplies and manages the team that builds the product, usually from design through testing and, in many cases, support after launch. In the US, you'd call it a software development company or a dev shop.

Is a software house the same as an outsourcing company?

A software house is one type of outsourcing company, but the term is narrower because outsourcing also covers work unrelated to building software, such as call centers and IT support. A software house builds custom software and is responsible for delivering it. Staffing agencies that place developers in your team are outsourcing too. You manage those developers yourself, though, which makes it a different model.

Who owns the code a software house writes?

You should, as long as the contract says so. Under US copyright law, work by an outside contractor isn't automatically yours. Your agreement needs a clear assignment of intellectual property to your company. At handover, you should receive the source code, design files, documentation, deployment instructions, and infrastructure access, and ideally the code lives in a repository you've owned from the first day.

How long does a software house project take?

At Milo, a straightforward project usually has about two weeks of discovery, with development starting around week four and a first version you can try by the end of the first build sprint. Complex products take longer, and Stepwise needed about two months of discovery workshops. Clutch's pricing guide, based on verified project reviews, puts the usual software development timeline at about 13 months.

1. US Census Bureau, "North American Industry Classification System: 541511 Custom Computer Programming Services," 2022 NAICS. Supports the definition and the separate Software Publishers industry (definition text confirmed via the NAICS Association reproduction). https://www.census.gov/naics/?input=541511&year=2022&details=541511
2. Collins English Dictionary via Dictionary.com, "software house," 2012 digital edition. Supports the British label and "computer software packages" definition. https://www.dictionary.com/browse/software-house
3. BCS, The Chartered Institute for IT, Simon Lavington, "A brief history of British computers: the first 25 years (1948 to 1973)," 2010. Supports the February 1959 founding of Vaughan Programming Services by Dina St Johnston. https://www.bcs.org/articles-opinion-and-research/a-brief-history-of-british-computers-the-first-25-years-1948-1973/
4. CISA, "Johnson Controls Software House C●CURE 9000" (ICSA-24-191-04), July 9, 2024. Supports the Software House brand name belonging to Johnson Controls. https://cisa.gov/news-events/ics-advisories/icsa-24-191-04
5. US Copyright Office, "Circular 30: Works Made for Hire," revised August 2024. Supports the nine categories and written-agreement requirement for commissioned works. https://www.copyright.gov/circs/circ30.pdf
6. Federal Acquisition Regulation 16.202-1, "Firm-fixed-price contracts." Supports the fixed-price definition and risk allocation. https://www.acquisition.gov/far/16.202-1
7. Federal Acquisition Regulation 16.601, "Time-and-materials contracts." Supports when time and materials applies. https://www.acquisition.gov/far/16.601
8. Clutch, "Software Development Pricing Guide," updated September 21, 2026. Supports the $25 to $49 hourly band, $132,480 average project cost, and 13-month average timeline. https://clutch.co/developers/pricing
9. US Bureau of Labor Statistics, "Occupational Outlook Handbook: Software Developers, Quality Assurance Analysts, and Testers," modified August 27, 2026. Supports median pay of $135,980 (May 2025). https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm
10. Eurostat, dataset isoc_sks_itspt, "ICT specialists in employment," updated April 17, 2026. Supports Poland's 778,800 ICT specialists (4.5% of total employment) in 2025. https://ec.europa.eu/eurostat/databrowser/view/isoc_sks_itspt/default/table?lang=en
11. Eurostat, "Number of ICT specialists in the EU continues to grow," May 27, 2026. Supports the EU's 10.45 million ICT specialists (5.0% of employment) in 2025. https://ec.europa.eu/eurostat/web/products-eurostat-news/w/ddn-20260527-2
12. Polish Investment and Trade Agency (PAIH), "Export of services as a driving force of Poland's GDP," September 18, 2024, citing the National Bank of Poland. Supports USD 13.4 billion in IT and telecommunications services exports in 2022, up more than 15% on 2021. https://www.trade.gov.pl/en/news/export-of-services-as-a-driving-force-of-polands-gdp/