Guide · starting a project
How do you get an app built?
You don't need to be technical to get an app built. You need to know what to prepare, who to approach, and what questions to ask.
Getting an app built means describing your need to a provider, who turns it into a precise scope before quoting, then building the app in stages, testing it early with your teams. You don't need to arrive with a full requirements specification: a clear problem and concrete examples are enough to get started.
Before contacting anyone
You don't need to write a full requirements specification before making contact. A serious provider knows how to turn a problem into a scope; that is even the point of scoping. What genuinely helps is a simple brief: who the app is for, what it must let them do first, the special cases you already know about, and the existing tools it will need to coexist with — a spreadsheet, current software, or a third-party account.
If you already have documents — spreadsheet exports, screenshots of the current tool, examples of special cases — bring them to the first conversation. They are what makes scoping fast and a quote reliable.
A simple brief often fits on a single page, written in your own words rather than technical vocabulary. Describe a typical day for the person who will use the app: what they do in the morning, what they need to check, what they currently note on paper or in a spreadsheet. That concrete description is worth more than a list of abstract features, because it shows the real constraints rather than a general idea of the need.
The steps to get an app built
The path is broadly the same whatever provider you choose, even if the vocabulary varies.
This path isn't rigid: depending on the size of your project, some steps merge or repeat. A small internal tool can go straight from scoping to a testable version in a few weeks. Larger business software will repeat the test-and-adjust steps several times before full go-live. What stays constant, though, is the order: scoping before quoting, and a testable version before rolling out widely.
- Describe the problem: what's not working today, not yet the solution.
- Scope it: a serious provider gathers your rules, your roles and your actual data before quoting.
- Receive a quote based on that scoping, with a written scope, not a blind estimate.
- See a first usable version, deliberately incomplete, to correct course early.
- Have it tested by the people who will actually use the app, not just management.
- Go live with training and documentation, not just an access link.
- Evolve the app over time, ideally with the same point of contact.
Who to approach
Three main options exist for getting an app built: a freelance developer, an agency, or a studio specialised in your type of need. Each has different strengths and limits, detailed in our comparison of freelancer or agency for app development. In short, a freelancer suits a simple, one-off need, a generalist agency suits a large project with several skills to coordinate, and a specialised studio suits business software, a field app or a SaaS that requires solid knowledge of those specific subjects.
The choice doesn't depend only on project size. A small app with very specific business rules can justify a specialised studio over a generalist freelancer, if those rules touch on an area — such as offline field work — where prior experience matters more than price.
Questions to ask a provider
Some questions quickly reveal how serious a provider is, before price even comes up.
- How does scoping work, and is it billed separately from development?
- Will the source code be pushed to my own repository, from the first commit?
- Will third-party service accounts (hosting, app stores, email) be in my name?
- How is migrating my existing data handled, and at what point in the project?
- Are user training and documentation included in the quote?
- What happens, contractually, if I want to change provider partway through?
Pitfalls to avoid
Some mistakes come up again and again among people getting an app built for the first time.
- Accepting a price quoted before any scoping: it is wrong one way or the other.
- Scoping only with management, without the people who will use the app day to day.
- Underestimating migrating existing data, almost always the longest item in the project.
- Waiting until the very end of the project to have the app tested by real users.
- Not checking who holds the source code and the third-party accounts once the project is delivered.
What a complete quote covers
A quote that names only development leaves out items that come back as a surprise later. A complete quote distinguishes at least the following steps, even if it cannot yet price all of them at the same level of detail.
Asking a provider for this table, or its equivalent, before signing lets you compare two quotes on equal footing. A provider who can't answer clearly on one of these items probably hasn't scoped your project enough yet to give you a reliable price.
| Step | What it produces | Often forgotten? |
|---|---|---|
| Scoping | A document of rules, roles and scope | Rarely, if the provider is serious |
| Migrating existing data | Clean, imported data | Yes, often underestimated |
| Development | The app itself, in batches | No |
| Training and documentation | Self-sufficient users | Yes, sometimes missing from the quote |
| Go-live | A reversible cutover | Rarely |
| Maintenance | Fixes and small changes | Yes, often handled separately, without being mentioned |
Frequently asked questions
How do you get an app built without technical skills?
By describing your problem, not a technical solution: what's not working today, who is affected, and what documents or files you already have. A serious provider turns this into a scope during scoping.
How do you get an app created without a requirements specification?
That's the most common case, not the exception. Scoping exists precisely to turn a problem into a written scope; a full requirements specification is not a prerequisite for making contact.
Do you need a requirements specification to get software created?
A simple brief helps: who the software is for, what it must enable first, known special cases. An exhaustive document is not necessary before the first conversation.
How long does building an app take?
It depends on the actual scope, the number of roles and, above all, the volume of data to migrate, which is almost always the longest item. A first usable version generally arrives faster than the complete app.
How do you create software that replaces a spreadsheet?
By first scoping what the spreadsheet actually does: its columns, its colour codes, its special cases noted in comments. These are unwritten business rules that the software must carry forward rather than ignore.
Can you get an app built remotely?
Development, yes, almost always remotely. The initial scoping, however, benefits from being done on site, with the people who will use the app day to day.
A project, a question?
Describe what you need in a few lines: you deal directly with the team, in Lille.