Before we build you an app, we work out which kind you need. A web app and a mobile app solve different problems, and picking wrong is the most expensive decision on the project.
.svg)
Almost every enquiry that starts with "we need an app" turns out to contain an unmade decision. These are the six shapes it takes, and none of them is solved by starting to code.
The word "app" is doing a lot of work in the brief. Half the room means something people install from a store; the other half means a web tool with a login.
The decision is usually settled by two questions rather than by preference: does it need anything only a phone has, like a camera, location, offline use or push, and where are your users when they need it. If the honest answer is "at a desk," a web app is faster, cheaper and easier to change.
There is a mobile app. Usage is thin and the analytics show most sessions happening on desktop-hours from office IPs, which is a strange pattern for something in a pocket.
It was built as a mobile app because that is what "app" meant to whoever wrote the brief. The good news is that the domain logic and the API are usually reusable; it is the client that was wrong, not the whole system, so this is rarely a start-again situation.
There is a real case for a customer facing mobile app and a real case for an internal web tool. The budget covers one of them properly or both of them badly.
Sequencing beats splitting. Build the one that generates evidence first, usually the internal tool, because it has captive users and tells you what the customer facing product should actually do. Two half-built clients on one budget is the worst of the available outcomes.
What is being described is a sequence of approvals, handoffs and notifications that currently lives in email and a spreadsheet. Somebody has called it an app because it needs a screen.
The screen is the small part. The value is in modeling the workflow properly, including the exceptions everybody knows about and nobody wrote down. Get that right and the interface is almost obvious; get it wrong and no amount of design rescues it.
The app is described mostly in terms of what the AI will do. The parts around it, accounts, data, permissions, what happens when the model is wrong, have not been specified.
The model is rarely the hard part now. The hard parts are whether your data can support the feature and what the app does on the days the output is wrong. We scope those first, because an AI feature with no fallback is a demo with a login screen.
You need something real enough to raise money or win a first customer, but the full build is months away and the funding depends on it.
This is a legitimate and common position, and it has a legitimate answer. On iCopy the clickable prototype worked as both the foundation for the build and the asset the founders sold with, which is a very different exercise from building a throwaway demo.
Four practices. Which of them you need is the output of the web-or-mobile conversation, not an input to it.
Contact us
Operator dashboards, internal platforms, customer portals and marketplaces. One codebase, deployed continuously, with the reporting layer that makes the operation measurable.
Native iOS and Android where the phone is genuinely part of the job, and React Native where the logic is shared and the interface is not the differentiator. An even 50 / 50 platform split on Clutch.
APIs, data modeling, integrations and the sync behavior that decides whether an app feels solid. Built once and shared, so choosing a second client later is not a second project.
Automation, predictive and natural language features scoped against your data rather than a demo, including what the product does on the days the output is wrong.
A web app, a mobile product with custom hardware, a two-sided marketplace, and a platform that started as a prototype used to sell. Every figure is published on that project’s own case study page.
One went web, one went mobile with hardware attached, one is a marketplace, and one started as a prototype. Same Chicago team on all four. We do not publish client head office locations, so read these as our work rather than as a claim about theirs.
Three steps to a plan, then phased delivery. On this page step one carries more weight than usual, because it is where the web-or-mobile question actually gets answered, usually in a room in our Chicago office rather than over email.
How we handle scope changes. Scope moves on almost every software project, and pretending otherwise is how budgets get broken quietly. We price and sequence in phases so a change is a decision you make at a milestone with the cost in front of you, rather than something you discover in an invoice. Our Clutch reviews are public, including the ones that mention budget and schedule, and we would rather you read them before the call than after it.
You talk to product people and an engineer rather than a sales rep, often the same day you get in touch. We want to hear the problem before the feature list, because the feature list is usually somebody’s first guess at a solution and it is worth testing.
You get a custom development plan within a week: scope, sequence, the team assigned, what the first milestone proves and what it costs. The plan is yours whether or not you continue with us, which is deliberate. It is hard to compare quotes when nobody will write down what they actually mean.
Phased execution with the named engineers who will do the work, not a bench you never see again after the pitch. You get a working increment early rather than everything landing at the end, because that is what makes a change of direction affordable instead of catastrophic.
For moving scope or ongoing support. Billed by time worked, so you can stop any time. Harder when you need a fixed budget first.
For a build with a clear finish line. One price per phase, agreed up front. Harder when each mid-phase change means a re-quote.
For engineers working inside your own team. Billed monthly per engineer, rolling with notice. Harder when nobody on your side can direct the work.
For discovery, a first release, then a live roadmap. Fixed to launch, then hourly or monthly. Harder for projects under about six months, where the model is overkill.
Bring the question, not just the spec. A short conversation with an engineer and a product person, and if we are not the right fit we will say so on that call. Or call 312‑298‑9598, or visit us at 20 N Wacker Dr in Chicago.
Contact us
Connect with one of our product specialists today.
.svg)
.svg)
