Blog

A software house is a company whose main business is designing and building custom software for other companies, and the client owns what gets built. In US terms, it's a software development company or dev shop, and the US Census Bureau classifies the work as custom computer programming services (NAICS 541511).

If you're talking to development firms in Poland or elsewhere in Europe, you've probably seen vendors call themselves a "software house" and wondered whether that's something different from a dev shop.

I run Milo Solutions, a Polish software house that works with US clients, and when a founder asks me whether we're just a dev shop, this is what I tell them:

Pretty much. "Software house" is the term we use in Europe for what you'd usually call a dev shop in the US.

How the work runs matters more than the label. Most of this guide follows one real engagement from the first call to handover, then covers the cases where I'd tell you not to hire a software house at all.

A proof of concept (PoC) tests whether your idea can be built, and a prototype tests whether people want it, while a minimum viable product (MVP) is the first working version that shows whether customers will pay, so the MVP vs PoC choice comes down to your riskiest question. Build the one that tests it first, and skip the rest.

Most founders who ask me for an MVP are about to pay for the wrong first build, which is why the first thing I tell them is the line I'd want you to remember:

Test the riskiest assumption first. A proof of concept tests the technology, a prototype tests the demand, and an MVP tests whether people will pay.

About six in ten of the MVP requests that reach Milo should start with something smaller, while the other four can go straight to an MVP because the technology is proven and the founder has already talked to real users.

If you have a half-built MVP or a backlog that grows faster than your team can ship, someone has probably offered to sell you a discovery phase before any more code gets written.

Product strategy services, often sold as a discovery phase, are paid work in which an outside team tests your riskiest assumptions with users and engineers before development starts. What you should get back is a roadmap phrased as outcomes and a scoped first release that a developer can start building from.

I run Milo Solutions, a software house, so my team has to build whatever a roadmap says. That gives me a blunt view of strategy work:

The most expensive thing a founder can build is the wrong thing, finished. You can't know it's wrong until you test it, and testing is always cheaper before the build than after.

Plenty of founders don't need to pay for this at all. If you do, you can judge a provider before signing by asking what you'll be held responsible for when the engagement ends.

The cost to develop a fintech app is the cost of a normal app plus regulated line items that most quotes leave out or bury: the regulatory route, a reconciling ledger, identity checks, card security scope, audits, and vendor fees. On our last fintech build, about half the engineering effort went into that work instead of features users can see.

Many of those lines keep billing you after launch through audits and per-user vendor fees. Published ranges disagree because one agency prices only the app while another quietly includes some of that work. You'll get a truer number by pricing each line yourself.

When a founder tells me they'll sort compliance out after launch, this is what I tell them:

Without compliance, you don't have a product. It sits at the core of every architectural decision: what we build and how we build it. A single missed requirement can mean a months-long rebuild, or a shutdown.

Good healthcare software design starts with two early decisions: work out which rules your product falls under, and test every important screen with the clinicians and patients who'll use it. Skip either one and you'll likely pay for a redesign after launch.

The usability bar in this industry is low: in a study of 870 US physicians published in Mayo Clinic Proceedings in 2020, doctors gave their electronic health record (EHR) a mean System Usability Scale score of 45.9 [1]. The System Usability Scale (SUS) is a standard 10-question survey that rates how easy software is to use on a 0-100 scale, and 45.9 falls in the bottom 9% of earlier SUS results, which is a grade of F.

I run Milo Solutions, a software house that builds web, mobile, and desktop products, and medical software is a small part of our work, but one belief from that work shapes everything in this guide:

If you haven't watched a clinician use your product, then you haven't tested it. You've only shown it to someone.

Most guides to NFT real estate marketplace development describe the same project: minting an NFT for each house and listing it on a marketplace with a wallet attached. Almost none of them mention that in the United States the token nearly always represents a security, or that what gets tokenized is a share in a company that owns the property rather than the deed itself.

A founder could follow that advice and commission a build, then discover at launch that the product can't legally be sold to most of the people it was designed for.

Three facts shape a US real estate tokenization platform. The token is usually a security, so the SEC's rules on offerings and resale apply to it. The token represents an interest in a legal entity, typically an LLC, that holds title to the property.

And the investor checks the law requires, such as KYC (know your customer) and accreditation, have to be enforced inside the token's transfer logic, because a check that only runs at sign-up is bypassed the moment tokens move between wallets.

When a founder tells me they want to mint NFTs of houses, I start by asking what they're trying to achieve by tokenizing the property, because that answer decides the legal structure, and the legal structure decides the architecture. Until we know the business goal and the legal requirements, there's nothing sensible to build, and the right choices on users and budget follow from those two.

One question separates a UX design service worth paying for from an expensive way to get pretty screens: does the agency run real research and test its designs with users, or does it just hand you polished mockups? Everything else, the portfolio and the talk of design thinking, sits downstream of that. An agency that researches and tests is designing for how people actually behave, while one that skips both is guessing in high resolution.

This guide is written from the side of someone who buys and runs design work rather than sells it, so it covers the three things a buyer needs and rarely finds in one place: what UX design services include, what they honestly cost, and how to choose an agency on the signals that predict good work. It also corrects the recycled return-on-investment numbers the whole category leans on, because the most-quoted one cannot be sourced at all.

When founders ask me how to structure a web development team, they usually want a list of roles: a product manager, a designer, some frontend and backend developers, QA, and someone for DevOps. That list is real, but it is table stakes, not what decides whether the team ships. Three decisions do that, and none of them appears on the org chart: how big the team is, the ratios between those roles, and the sourcing model you use to staff it.

Get those right and a small team delivers steadily, week after week. Get them wrong, and you can assemble every role on the list and still watch delivery slow to a crawl as the team grows. This guide gives the real numbers behind those three decisions, drawn from 14 years of building and running these teams, along with the trigger for when each specialist role earns a dedicated hire rather than being spread across developers who already have a full job.

Most founders who come to us with a marketplace idea think the platform is the hard part, and they arrive with wireframes for listings, search, and checkout, wanting to know how long the build will take, which is the part I worry about least. Whether an online marketplace development company can make your platform actually work comes down to two things, and neither is a feature: liquidity, meaning both sides show up and transact, and how money moves between them without dragging you into licensing you never planned for.

Get those two right and a plain platform will trade, but get them wrong and you can launch a polished two-sided marketplace that sits empty, or one that quietly turns you into an unlicensed money transmitter. This guide is written from the side of the engineer who wires up split payments and has watched the cold-start problem sink a launch. It covers the marketplace models, liquidity, how money should move, trust and disputes, and when a packaged platform beats a custom build.

The model itself is proven: online marketplaces reached 62% of global retail ecommerce sales in 2024, about $2.4 trillion, with third-party sellers growing from 72% of marketplace revenue in 2014 to 81% in 2024, according to Euromonitor. More than 60% of sales in Amazon's store now come from independent sellers. The question is never whether the model works, but whether yours will reach liquidity before the money runs out.

Most retailers who come to us want dashboards, and they usually have a business intelligence tool in mind; sometimes they have already bought one, and want sales, stock and customer numbers on one screen the whole trading team can see, and the dashboard is the easy part.

Whether business analytics and business intelligence solutions in retail actually pay off comes down to three things, and only one is the software: the data underneath it, the decision each view is tied to, and whether anyone changes what they do because of what they see.

Get those right and a modest set of reports earns its keep. Get them wrong, and you can spend six figures on a clean dashboard that quietly misleads the people reading it, because the numbers were never reconciled.

This guide is written from the side of the person who has to make retail data add up:

• what to unify first
• where analytics returns money soonest
• how to tell a trustworthy dashboard from a wrong one
• how to choose between buying a tool and building one.