Preparing your app or software project: a guide to getting started right

By the NRX3 team · Updated October 23, 2026

You have an idea for an app, or a problem that custom software could solve. Before calling a developer, a few hours of preparation make a big difference: on price, timelines and the result. You don't need to be technical to do them well.

1. Describe the problem, not the solution

The best starting point isn't a list of features, it's a description of what isn't working today. Answer in writing, in your own words:

• What is costing you time or money today?
• How is the work done right now: files, paper, email, other software?
• Who will use the tool: your employees, your customers, your members? On what device, and where: at the office, on the job site, at the counter?
• How will you know the project succeeded, six months from now?

One page is enough. It's worth more than a long specification written in vocabulary that isn't yours.

2. Separate the essentials from the "nice to have"

Make three columns: what's indispensable from day one, what would be useful later, and what's a bonus. A first version limited to the essentials costs less, ships sooner, and teaches you a lot about what your users really want.

3. Gather what already exists

• Your current files, forms and reports: they're the best examples of your data.
• The software you use, which the new tool will need to exchange information with.
• Screenshots of apps you like, or find frustrating.
• The rules that apply to you: personal information, industry standards, customer requirements.

4. Prepare your budget

The price of custom software depends mostly on its scope: the number of screens and rules, the links with other systems, the level of security required, and the target platforms (web, iPhone, Android). A few tips:

• have a range in mind and say it: a good provider fits the scope to the budget rather than the other way around;
• also plan for after delivery: hosting, updates, support, improvements;
• be wary of a very low price for a poorly defined project: the surprises often come later.

5. Choose your provider

Ask these questions and compare the answers:

• How will you understand our business before building?
• When will we see a first version to try? How often after that?
• How will we track the budget and progress?
• Who reviews and tests the code? How is security handled?
• Who owns the code, the data and the documentation at the end?
• What happens after delivery if something doesn't work?
• If you use AI to develop, how do you check what it produces?

Get the answer on ownership written into the contract: in Canada, without a written agreement, code written by an outside provider generally belongs to that provider.

6. During the project

• Try every version and give feedback quickly: changes cost the least at the beginning.
• Keep one person in charge on your side, with the time to answer and the authority to decide.
• Involve real users early: the people who'll do the work every day see problems managers don't.
• Write down decisions, so they aren't reopened at every meeting.

Warning signs

• Nothing to see until the very end.
• A budget that keeps climbing without a clear explanation.
• Vague answers about who owns the code or your data.
• Technical vocabulary nobody takes the time to explain.