How Discovery Creates Alignment Before Development
A pattern we observe is that the push to show early progress can mean teams begin development before the requirements are fully defined. They don’t do this out of carelessness. Usually, they start writing code due to pressure to show progress.
At Soliant Consulting, we run a discovery phase before any production code gets written. It doesn’t produce a working application on its own, but what we’ve learned over 21+ years of building custom software is that it’s a major factor in whether a project succeeds.
Here’s what that discovery phase actually involves.
We Don’t Know What We Don’t Know
We run discovery sessions at the start of every project because we don’t know what we don’t know about an application (existing or envisioned) in our first call with a client.
That sounds obvious, but this process has huge implications for a project. When a client first describes what they want to build, we’re looking at the application from about 5,000 feet. The vision is clear, but the details aren’t. And the details are where cost and timeline actually live.
Our team uses these discovery sessions to close that gap at the beginning of our custom application development projects. We work with the client to document the full scope of what the application needs to do, identify the integrations it needs to support, and surface the use cases that aren’t obvious until someone starts asking the right questions. By the end of discovery, we have something concrete enough to build an honest estimate around.
A Working Prototype Changes What Clients Can React To
Once discovery gives us a clear enough picture, we build a prototype. Important note: a prototype and a set of static wireframes are not the same thing.
We use AI-assisted tools to rapidly build functional interface mockups so clients can get their hands on an interface right away. They can see their vision in an interactive interface, not just a description of one.
Because we build it quickly, we can also change it quickly. For a client who looks at a screen and says the navigation doesn’t feel right or that a workflow is missing a step, we can get it fixed before a single line of production code is written. At this point, this change represents an opportunity for improvement. A change like this at the end of development represents a challenge, and possibly an expensive one.
We use the prototype as the direct input for the next step.
Turning a Prototype into a Build Plan the Development Team Can Use
Once the prototype is solid, we hand it off to the development team as user stories. We break down every screen and workflow in the prototype into discrete, testable pieces of functionality. Each one becomes a unit of work that the team can build, review, and ship independently.
As an agile firm, we leverage user stories to provide the development team with a prioritized, estimable build plan. These user stories also give clients consistent visibility into the project’s status throughout development.
The step also requires a conversation about prioritization. When you see a full application broken down into individual stories, it becomes a lot easier to be honest about what belongs in version one and what can come later. That’s generally where the MVP discussion gets concrete.
Non-functional Requirements: The Conversation Most Projects Skip
The foundation phase also covers non-functional requirements, something some clients don’t even know to ask about.
Functional requirements cover what the application does. Non-functional requirements cover how the application behaves when things don’t go as expected. On any custom application development project that integrates with external platforms or systems, that second conversation is more important than most clients realize.
For example, a client portal that connects to a billing system, a document platform, and a CRM will encounter moments when one of those back-end connections has an issue. So, what does the user see when that happens? Does the application fail in a way that’s confusing or alarming? Or does it surface a clear, helpful message and degrade gracefully?
Our team works through those scenarios during the foundation phase to get a real understanding of how important it is to code around each one. Handling errors gracefully takes time, and that maps directly to budget. Clients who skip this conversation tend to run into it later, when it costs more to address.
A Custom Application Development Partner that Prioritizes Foundation
The foundation phase is how our team turns a good idea into a project we can build and deliver with confidence. It takes significant investment upfront. That’s why our clients typically ship on schedule, within budget, and with a product that works the way they envisioned it. If you’d like to walk through what the foundation phase would look like for what you’re building, contact our cloud-native application team. We’re happy to share our initial insights.
