Open three tabs from a search for custom software development services and you’ll get the same diagram three times in different colors, running from discovery and design through build, test, deploy, and support. We read three of the pages competing for this phrase while writing this one, and all three lay out that lifecycle at about the same level of detail, with much the same claims of breadth attached to it. What none of them gives you is a scope: which of those phases the number at the bottom of the proposal covers, who is assigned to each one, and what you’re holding on the morning after the last one ends.

That gap is the whole problem, because the diagram is identical everywhere and the agreements underneath it are not. Two firms can publish the same six-phase process and then hand you contracts that disagree about who writes the specification, whether the engineers in the pitch deck are the ones who’ll do the work, and whether next year’s bug fixes are already paid for. So what follows is a way to find those differences in a proposal, since the services page won’t point them out for you.

It’s easier to see the pattern against specifics, so take the three pages in turn.

Intellias lists seven industry verticals, running from financial services and insurance through retail, healthcare, telecom and media, travel and hospitality, iGaming, and agriculture, and it backs that breadth with more than 2,000 in-house developers across seven engineering centers plus access to a talent pool it puts at 500,000 people. Alongside those numbers sit four analyst-recognition badges and four case studies, all of them anonymized. The page claims work for 45 Fortune 100 companies without naming any of them, gives no pricing, and says nothing about who owns what or what happens after launch.

Itransition runs the six-phase version: initiation, design, planning, development and testing, deployment, and then support and maintenance. It claims more than 20 industries and more than 3,000 IT professionals, and its FAQ is the most useful thing on any of the three pages, because it admits that the engagement can be full project outsourcing, a dedicated team, or team augmentation. What it never says is which of those three a given quote assumes, so the same page can produce agreements that feel nothing alike to the people who sign them.

Spiral Scout is the most checkable of the three. Seven clients are named outright, one in the hero case study and six more in the carousel below it, with Qualcomm and Temporal among them; the tooling is broken out by category across more than 40 entries; and the process is stated plainly as discovery, then agile development, then deployment. Even here, though, the IP-ownership claim is a headline with nothing behind it, no pricing or engagement structure appears anywhere, and team size is undisclosed past two named co-founders.

All three describe the lifecycle and none of them scopes it, so an hour of reading leaves you with three phase diagrams and no way to hold one quote against another.

Almost every real difference between two custom software quotes sits at one of four boundaries, and all four are settled in the paperwork rather than on the services page. None of them requires a lawyer to spot, either; they’re readable off the proposal itself, usually off the scope section and the payment schedule.

Itransition’s first two phases are initiation and design, and Spiral Scout opens with discovery, but neither page says whether that work is covered by the figure at the bottom of the proposal or sold separately as the engagement that produces the figure. Both structures are legitimate and both are common, and they lead to different conversations. When discovery is billed on its own, the first number you’re given isn’t the project price at all, because there is no project price yet; you’re buying a specification and an estimate, and the estimate arrives at the end.

So ask what discovery actually delivers, in artifacts you could hand to another firm: a written spec, a data model, wireframes, a revised range. Ask who keeps that document if you stop there, and whether the build estimate that comes out of it is a cap or a fresh quote. Then read the payment schedule, because if the first milestone comes due before any named deliverable, discovery is being billed on its own whether the page says so or not.

Intellias’s 2,000 developers and 500,000-person talent pool, and Itransition’s 3,000 IT professionals, are real assets, but a roster only tells you how big the company is. The contract version of the question is whether the agreement names people or names roles. A staffing exhibit that reads “two senior engineers, one QA analyst, half a project manager” is a rate card, and it gives the vendor standing to put anyone carrying those labels on your work at any point in the project. So ask for named individuals with a stated allocation, and read whatever the agreement says about substitution and notice.

Since Itransition lists three engagement models and never attaches them to quotes, ask which one you’ve been quoted under, because full project outsourcing and team augmentation put responsibility for architecture in different places. It’s worth asking the same of any vendor that advertises a bench, since a bench can mean the people who will work on your project or only the people who would replace them.

None of the three pages says who holds the repository, the hosting account, and the deploy credentials while the work is underway, or at what moment those move to you. Spiral Scout’s IP-ownership headline doesn’t settle it either, because owning the code and being able to deploy it next Monday without the vendor are two separate sentences in an agreement. We wrote out the full list of accounts to settle before signing, and how each one tends to go wrong, in outsourcing web app development; the short version is that it belongs in the signed scope, account by named account, before anyone writes code.

Itransition gives support and maintenance a single line as its sixth phase, and Intellias says nothing about post-launch terms at all. This is the boundary that costs the most to leave open, because the week you’d most want to negotiate it is the week you’re busiest getting a new system into people’s hands.

Four questions cover most of it. After go-live, is the work you’ll want covered by the agreement you’re signing now or by a new one, and is that decided now or then? What separates a bug from a change request, and against which document is that judged? The answer is usually the spec that came out of discovery, which is why this boundary and the first one tend to move together. Is there a response window, with real hours attached to it, for a production problem? And is the rate for post-launch feature work fixed in the agreement in front of you, or quoted at the time you ask for the feature?

These four boundaries assume you’ve already decided you want something built from scratch, and they will not test that assumption for you. A firm selling heavily configured platform work can answer all four of them cleanly and still not be building you custom software. That’s a different question with its own checks, and we went through it in bespoke software development services, which walks through what gets sold under that label and how to tell which version you’re being offered. If you haven’t settled whether to build at all, start further back with what to know before commissioning a custom web application, which covers build versus buy and what drives the cost of a build.

One concession the small-shop version of this argument usually skips: sometimes breadth is exactly what you should be buying. If your project touches four industries at once, needs a data practice sitting alongside the application work, or has to be staffed up quickly and stay staffed through someone leaving mid-year, then a bench of two thousand engineers is a real advantage, and it isn’t something a small team can improvise. A talent pool the size of Intellias’s is worth real money to a buyer with that problem, and the vertical list is a fair thing to shop on.

The other shape looks nothing like that: one product, on one stack, that has to be owned and extended for years instead of delivered and handed over. There the vertical list stops carrying much weight and the four boundaries decide nearly everything, because what you’re paying for is whoever will still be answering questions about this codebase in three years.

That second shape is where we work. We’re a Ruby on Rails consultancy in Coronado, California, founded in 2015, working in Rails and Postgres with a small senior team. AI writes the code here, with senior engineers directing and reviewing every change, and we hold client projects at 80 to 90 percent test coverage, which is the cheapest available evidence that the review is real. Our longest-running engagement has a public page you can read for yourself: The Wine Spies.

Before you send out a single request for a quote, write down your own answers to the four boundaries: whether you expect to pay for discovery as its own phase, whether you need named engineers or are fine with roles, what you have to be able to do without the vendor on any given morning, and how long after launch you expect the work to still be covered. It’s a twenty-minute exercise, and it turns three proposals you can’t compare into three answers to the same four questions.

Then read each proposal looking for where those four boundaries actually sit in it, and where a proposal is silent on one, ask before the call ends. Silence is the common case here, not a warning sign, and asking is usually enough to get the answer in writing.

Two more pointers, depending on where you’re standing. If you’re in San Diego and would rather work with someone nearby, custom software development in San Diego is the page for that, and if the stack turns out to be Rails, how to choose a Ruby on Rails development company covers the questions specific to it. The full ownership and exit mechanics behind the third boundary are in outsourcing web app development. And when you want to talk through your own four answers with someone, you can book an intro call.