Custom Software Discovery: The Two-Week Start

• Discovery is a short, paid phase that defines the problem, the scope, the risks and the cost before building.
• It starts by watching the work, not by listing features.
• It maps every system, data source and connection the software will touch.
• It sorts features into must have, should have and later, so the first version stays small.
• It ends with a written scope, a prototype, a risk list and an estimate with a range.
• You own everything discovery produces, whether or not you build with the same team.

This guide walks through a two-week discovery: who takes part, what happens each day, what you get at the end, and how to decide what comes next. Put plainly: spend two weeks learning the work so the build solves the right problem the first time.

Agreeing on the problem. What's broken, who it affects, what it costs today and what success looks like.

Finding the hidden work. Exceptions, workarounds and approvals that nobody mentions until the software doesn't handle them.

Reducing risk. Spotting hard integrations, poor data and unclear rules before they become expensive.

Getting a real estimate. A quote based on a defined scope, not a guess from a short call.

Deciding whether to build at all. Sometimes discovery shows that configuring or connecting existing tools is enough, as covered in when off-the-shelf stops fitting.

A decision maker. One person who can approve scope and budget.

The people who do the work. The staff whose day the software will change. They know the real process.

Someone who knows the systems. Whoever manages your current tools, accounts and data.

The build team's lead and designer. To ask questions, sketch screens and judge what's hard.

Short sessions, not long meetings. Most people need only a few hours across the two weeks.

Agree on the problem, who it affects and how success will be measured. Collect existing documents, reports, spreadsheets and screenshots.

Sit with the people doing the job. Follow real tasks from start to finish. Note every workaround, spreadsheet, copy-and-paste step and approval.

List every tool, account and data source involved. Check data quality: duplicates, missing fields, inconsistent formats. Note which systems have APIs, using the approach in API integration.

Write what the software must do, in plain language. Sort each item into must have, should have and later. Keep the first version as small as possible, the same discipline as in MVP development.

Sketch or click-through the main screens and test them with the people who'll use them. Fix misunderstandings now, while they're cheap.

Choose the approach for each part: build, buy, configure or connect. Decide how each connection will run, as weighed in integration platforms vs custom API work. List the risks and how to reduce each one.

Turn the scope into an estimate with a range, and a phased roadmap: what's in the first version, what comes next, and what the timeline looks like.

A problem statement. What's being solved, for whom, and how success will be measured.

A process map. How the work runs today and how it will run with the software.

A system and data map. Every tool, data source and connection, with data quality notes.

A prioritized feature list. Must have, should have and later.

A prototype. The key screens, tested with real users.

A risk list. What could go wrong and how to reduce it.

An estimate and roadmap. Cost range, phases and timeline for the first version and beyond.

All of it is yours. You can use it with any team, including your own.

It's real work. Two weeks of interviews, observation, design and planning by experienced people.

It protects you. Quotes given without discovery are guesses, often padded or later revised upward.

It's small compared with the build. A short discovery is a fraction of the project's cost and can prevent its most expensive mistakes.

It gives you a clear exit. If discovery shows the project isn't worth it, you've spent a little to avoid spending a lot.

A fixed quote after one call. Nobody can price custom software reliably without understanding the work.

Features before problems. A team that starts with screens and features instead of the problem will build the wrong thing efficiently.

No time with the people who do the work. Managers often describe the official process, not the real one.

No data review. Poor data is one of the most common reasons projects run over. It's covered in the foundation every AI project needs.

You don't own the outputs. Discovery documents should belong to you.

Build. Approve the first phase with a clear scope, budget and timeline.

Adjust. Narrow the scope, change the approach or fix data first.

Don't build. Configure or connect what you have, if discovery shows that's enough.

Start small either way. Run the first phase as a pilot, following AI pilots that fail safely.

Scope changes during the build. Fewer surprises mean discovery found the real work.

Estimate accuracy. How close the final cost of the first phase came to the estimated range.

User acceptance. Whether the people doing the work recognize their process in the result.

Hours returned after launch. Measured against the baseline discovery recorded, as with automation KPIs.

Run the two-week discovery, review the outputs with your decision maker, and decide whether to build, adjust or not build.

If building, start the first phase with the agreed scope. Keep the people who do the work involved in weekly reviews of working software.

Launch the first phase to one team, measure hours returned and errors removed against the discovery baseline, and plan the next phase from what you learn.

Astra Results Marketing starts every custom software project with discovery. We watch the work with the people who do it, map every system and data source, sort features into must have, should have and later, and test a prototype before anything is built.

You get a written scope, a risk list and an estimate with a range, and you own all of it, whether you build with us or not. Engagements begin with a two-week discovery through our custom software team.

Related reading

• Custom Software: When Off-the-Shelf Stops Fitting
• MVP Development: Launching the Smallest Useful Product
• Integration Platforms vs Custom API Work

A short, usually paid phase before building custom software. It defines the problem, maps the current work, systems and data, prioritizes features, tests a prototype and produces a scope, risk list and estimate.

It's long enough to watch the real work, map systems and data, and test a prototype with users, and short enough to keep cost low and decisions moving. Larger projects may need more time.

A decision maker, the people who do the work, someone who knows your current systems, and the build team's lead and designer. Most of your staff need only a few hours.

A problem statement, process map, system and data map, prioritized feature list, tested prototype, risk list, and an estimate with a range and roadmap. You own all of it.

Yes, and that's a good outcome. Sometimes configuring or connecting your current tools solves the problem for far less than a custom build.

Because custom software can't be priced reliably without understanding the work, systems and data. Quotes without discovery are guesses that are often padded or revised upward later.

Ready to know exactly what to build before you build it? Astra Results Marketing runs a two-week discovery that watches the real work, maps your systems and data, tests a prototype and delivers a scope, risk list and estimate you own, whether you build with us or not. ▸ CALL (786) 321-2866 · ▸ REQUEST YOUR CONSULTATION