The First Step When Working With Us: Discovery
Archie Norman
If you’re thinking about building a custom web application, improving an existing Rails app, or using AI to reduce manual work, the first question (after “how much will it cost?”) is usually “where should we start?”
That’s what discovery is for.
At mmtm, every project starts with a focused discovery step. It gives you clarity before committing major time, budget or internal attention. It also helps us understand what success looks like, what risks need managing, and which route makes the most commercial sense.
For business owners, product leads and operations teams, discovery turns a vague challenge into a practical next step.
Why Discovery Matters Before Building Or Improving An App
The biggest risk in software usually isn’t how the app gets built. It’s building the wrong thing, improving the wrong part, or starting with assumptions that haven’t been tested.
That applies whether you’re launching a new product, taking over an inherited Ruby on Rails application, or looking at AI automation for internal workflows.
A good discovery process helps answer questions like:
- What problem are we actually trying to solve?
- Who will use the application, and what do they need from it?
- What should the first useful version include?
- What risks, dependencies or technical constraints need to be understood early?
- What’s the most sensible route forward in terms of budget, timing and business value?
You don’t need to arrive with a technical brief. In fact, many of our best projects begin with a business problem, a messy existing process, or an app that’s become hard to maintain.
Choose The Right Discovery Route
There are three common ways to get started with mmtm. The right one depends on where you are today.
Route 1: New Product
Best if: you have an idea for a new platform, SaaS product, internal tool, marketplace, booking system or customer portal, but you need help turning it into a clear plan.
This route is usually built around a Product Discovery Workshop. We work with you to understand the opportunity, users, workflows, commercial goals and first-release priorities.
It’s a practical way to move from “we think there’s something here” to “this is what we should build first, and this is how we’ll approach it.”
Typical outputs
- A clear first-release scope.
- Prioritised features and user journeys.
- High-fidelity mockups or a clickable prototype where useful.
- A technical delivery plan written for decision-makers, not just developers.
- A recommended budget, timeline and delivery route.
This is often the right place to start if you’re asking how to get started with a web application and want a confident plan before moving into design and development.
Read more about our Product Discovery Workshop, or explore how we create a product.
Route 2: Existing App
Best if: you already have a web application, but it’s become difficult to change, expensive to support, slow to improve, or risky to maintain.
This is common with business-critical Ruby on Rails applications. The app may support internal operations, paying customers, reporting, bookings, compliance, payments or other important workflows. It may still work, but every new feature, fix or upgrade feels harder than it should.
For this route, we usually start with a Codebase Audit. We review the product, codebase, infrastructure and delivery setup, then translate the technical picture into clear business recommendations.
Typical outputs
- A documented view of what’s working and what isn’t.
- A review of Rails version, dependencies, infrastructure and upgrade risk.
- Clear risks around technical debt, maintainability, security and stability.
- A prioritised plan for Ruby on Rails app maintenance, upgrades, refactoring or feature work.
- Recommended routes forward based on cost, risk and business value.
The aim isn’t to create a scary technical report. It’s to help you understand what you’ve got, what needs attention, and how to improve the app without disrupting the business.
This route is a good fit if you’re considering a Rails upgrade, looking for a new technical partner, or trying to decide whether to improve, rebuild or maintain an existing product.
Explore how we improve a product.
Route 3: AI Automation
Best if: your team is spending too much time on repetitive admin, reporting, customer communication, document handling or manual decision support, and you want to know where AI could genuinely help.
AI can be useful, but only when it’s tied to a real workflow. The goal of an AI Audit isn’t to add tools for the sake of it. It’s to identify where automation could save time, reduce cost, improve service, or remove friction from your team’s day-to-day work.
We start by understanding how your business operates, then look for practical opportunities where AI, automation or better integrations could make a measurable difference.
Typical outputs
- A clear view of where AI is worth exploring, and where it probably isn’t.
- A tailored AI Playbook with recommended tools, workflows and next steps.
- Prioritised automation opportunities based on effort, value and risk.
- Practical guidance on implementation, adoption and safeguards.
- A follow-up conversation to help you decide what to do next.
This route is especially useful when you know your team is losing time to manual processes, but you’re not sure which AI use cases are realistic, safe or commercially worthwhile.
Learn more about our AI Audit.
Which Route Is Right For You?
Here’s the simple version:
- New product: choose this if you need to shape a new custom web application before committing to a build.
- Existing app: choose this if you already own an app and need clarity around support, upgrades, maintenance or future development.
- AI automation: choose this if you want to understand where AI could reduce manual work or improve internal operations.
If more than one route sounds relevant, that’s normal. A business may have an existing Rails app that needs maintenance and an internal workflow that could benefit from AI automation. Or a new product idea may need discovery before AI features are considered.
The point of the first conversation is to choose the route that gets you useful answers fastest.
What Happens After Discovery?
Discovery gives you a clear next step. That might be a scoped product build, a staged improvement plan, a Rails app maintenance roadmap, an AI implementation project, or a decision not to build yet.
That last option matters. Good discovery should help you avoid unnecessary work as much as it helps you plan useful work.
When the right next step is to continue with mmtm, discovery also gives the project a stronger foundation. We already understand the context, priorities and risks, so design, development or support work can begin with fewer unknowns.
Martin Dick
Co-Founder, mmtm
Need a hand taking your business to the next level?
We've spent the last 10+ years helping businesses like yours build and improve the right digital products for their processes, supporting hundreds of thousands of users.
Whether you're interested in automating a manual process or improving an existing platform, I'd love to share some ideas!
Book a call with MartinDiscovery FAQ
What is software discovery?
Software discovery is the planning step before design, development or technical improvement work begins. It helps define the problem, users, priorities, risks and route forward, so you don’t commit budget before the important questions have been answered.
Do we need discovery if we already have a brief?
Often, yes. A brief is a useful starting point, but discovery tests whether the scope, assumptions and priorities are right. It can also reveal simpler, safer or more cost-effective ways to reach the same business goal.
Can discovery help with an existing Ruby on Rails app?
Yes. For an existing Rails application, discovery usually means a focused codebase audit. We review the product, codebase, infrastructure and maintenance risks, then recommend a practical route for support, upgrades, refactoring or further development.
What if we’re not technical?
That’s completely fine. Discovery is designed to make technical decisions easier to understand. We explain findings in plain English and connect recommendations back to business impact, cost, risk and user experience.
Will discovery tell us how much the project will cost?
For a new product, discovery can usually define a recommended first-release scope, delivery route, timeline and budget. For an existing app, it can help identify whether the next investment should go into maintenance, upgrades, stabilisation, feature work or a deeper rebuild conversation.
Is AI automation part of product discovery?
Sometimes. If AI is central to a new product, we’ll consider it during product discovery. If the goal is to improve internal operations, reduce admin or automate business workflows, an AI Audit is usually the better starting point.
What happens after discovery?
You’ll have a clearer route forward. That may lead into a product build, an improvement plan, Ruby on Rails app maintenance, an AI automation project, or a decision to pause until the business case is stronger.
Not Sure What To Read Next? Here's What We Recommend...
- Technical Partnership
- Our Services
- AI
- App Development