Skip to main content
MNFInfotech
Process

How the work actually runs

Eleven stages, four phases, and a plain account of what happens at each one — what you receive, what we need from you, and what typically goes wrong. Not every engagement runs the whole sequence, and this page says where it does not apply.

  • Eleven stages
  • Four phases
  • Measurement before spend
Eleven stages, and where they do not apply

Not every engagement runs all eleven stages, and a process document that pretends otherwise is marketing. A campaign engagement starts at stage 09 and borrows stage 07. A rescue project usually starts at 05, because the code already exists and the argument about architecture has already been lost. A single API integration may touch four stages and skip the rest. The sequence below describes the full arc of building and growing a product, not a package anyone is obliged to buy.

What each stage really marks is a decision that becomes expensive to reverse later, and an artefact that records it. Stages are not week-long boxes on a chart; some take an afternoon, some run for months, and several overlap deliberately. What we hold to is the order of the decisions. Choosing a database before understanding the data, or buying traffic before defining a conversion, is the kind of ordering mistake that no amount of later effort fully corrects.

The page is also here so you can hold us to it. Each stage below names what you receive and what we need from you, because the most common cause of a stalled project is not engineering difficulty — it is a decision waiting on somebody. Read the client role lines as seriously as the deliverables. If a stage looks like something your own team already does well, say so early and we will scope around it rather than charge you to repeat it.

Phase map

Eleven stages, four phases.

  1. Definition

    01–04

    Four stages that end before a line of production code is written. Their job is to make the expensive decisions — problem, scope, architecture, interface — while changing your mind still costs a conversation rather than a rebuild.

    • 01
    • 02
    • 03
    • 04

  2. Delivery

    05–08

    Building, proving and releasing. Code, tests, instrumentation and the release itself land together in slices you can watch running, so the first honest build arrives early rather than as a reveal at the end.

    • 05
    • 06
    • 07
    • 08

  3. Growth

    09–10

    Where the build meets the market. Acquisition is structured against the signals stage 07 installed, and optimisation changes whatever the evidence points at — the product, the data or the campaign, whichever is actually wrong.

    • 09
    • 10

  4. Continuity

    11

    What happens after the launch email. Someone stays contactable, dependencies keep moving whether or not anyone is watching, and the arrangement is written down rather than left to goodwill and a half-remembered obligation to answer emails.

    • 11
Stage by stage

What each stage is for, and what comes out of it.

  1. Definition

    Discovery

    Establish what is actually holding the outcome back before anyone proposes a way to fix it.

    Most enquiries arrive with a solution already attached — an app, a redesign, a bigger budget. Discovery tests that assumption against what exists: the current product, the analytics property, the ad account, the support inbox, the spreadsheet somebody maintains by hand. We look for the constraint that is genuinely binding, and we say when the answer is that nothing should be built yet. The common failure mode here is agreeing to build the thing that was asked for without asking what it is for.

    You receive

    • A written statement of the constraint and the evidence behind it
    • An audit of the existing product, data, accounts and infrastructure
    • A short list of what is not worth building yet, with reasons
    • A recommended route: which of the stages below apply, which can be skipped, and what each one depends on

    Your part

    • Read-only access to whatever already exists: analytics, ad accounts, repositories, dashboards
    • An honest account of what has already been tried and why it stopped
    • One person who can say what the business is actually optimising for
  2. Definition

    Requirements

    Turn the agreed problem into written scope, acceptance criteria and the measurement attached to each.

    Scope is written as inclusions and exclusions, because an unwritten exclusion becomes an argument in month three. Every requirement that claims a business effect gets its measurement defined at the same time: if a feature is meant to raise activation, we agree what an activation is, where the event fires and what value it carries. Acceptance criteria are written so someone outside the project can check them. Requirements that cannot be tested are either rewritten or dropped here, not discovered later.

    You receive

    • A scope document with explicit inclusions and, more importantly, exclusions
    • Acceptance criteria written in language a non-technical reviewer can verify
    • An event and conversion model: names, parameters and value definitions
    • A change-request route agreed before anything needs to change

    Your part

    • A named decision-maker who can approve scope without convening a committee
    • Written sign-off on the exclusions, not only on the inclusions
    • Any compliance, contractual or regulatory constraint we would not otherwise know
  3. Definition

    Technical architecture

    Decide the data model, service boundaries and dependencies before they become expensive to change.

    We model the data first — entities, relationships, cardinality, what must be transactional and what can be eventually consistent — because schema mistakes outlive every framework choice. Then service boundaries: what belongs in one deployable, what needs its own, and which contracts cross the line. Third-party dependencies are assessed for lock-in, pricing at volume and what happens when they are down. Build-versus-buy is decided explicitly. We name what breaks first as volume multiplies, usually a database query or a synchronous call sitting in a request path.

    You receive

    • A data model with entities, relationships and the migration path from what exists
    • Service boundaries and typed API contracts, including error semantics
    • A dependency register: each third party, what it costs at volume, and the exit route
    • A written load note naming the first component to fail and at roughly what multiple

    Your part

    • Access to existing schemas, integrations and whatever documentation survives
    • A decision on build-versus-buy where the trade is commercial rather than technical
    • Realistic volume expectations, including the seasonal peak nobody mentions
  4. Definition

    UX & UI planning

    Design the flows, states and interface decisions around the tasks users actually need to complete.

    Flows are designed against real tasks on real devices, and the unhappy paths get as much attention as the happy one — empty, loading, partial, failed, offline, and the state where a permission was refused. A component and type scale is settled here so implementation is not a series of one-off decisions. Contrast, target size and focus order are chosen now, when they are free. The usual failure is a beautiful primary flow sitting on top of undesigned error states.

    You receive

    • Screen and flow designs covering primary, empty, loading, error and offline states
    • A component set and type scale carried straight into implementation
    • Interface copy for buttons, errors and empty states, written rather than left to the developer
    • Accessibility decisions recorded: contrast ratios, target sizes, focus order

    Your part

    • Brand assets and any existing design system, or a decision to create one
    • Review of the flows against how your business really operates, including the exceptions
    • Final wording for anything legal, regulatory or commercially sensitive
  5. Delivery

    Development

    Write the application, services and integrations to the agreed architecture, in vertical slices.

    Work lands as vertical slices — interface, data access, error handling and events together — so each one is genuinely usable rather than a layer waiting for the next. Code goes into your repository from the first commit, with readable history and no build step that only works on one machine. Configuration is separated from code and secrets stay out of the repository. Reviews happen against the contracts agreed in stage 03, which is what stops architecture quietly eroding under delivery pressure.

    You receive

    • Application and service code in your repository, with commit history intact
    • Working builds on a test track or preview environment as slices land
    • Environment configuration and a documented local setup someone else can run
    • A running list of decisions taken during the build and the reasoning behind them

    Your part

    • Timely answers on the questions that block a slice, usually within a working day
    • Credentials and sandbox access for third-party systems we must integrate with
    • Review of each slice as it lands, rather than a single review at the end
  6. Delivery

    Quality assurance

    Prove the build behaves correctly across the devices, states and edge cases it will meet.

    Testing runs against an agreed matrix: browser versions and viewport sizes for web, an OS-version and device-class spread for mobile, including the slow, small, old device your analytics says people still use. We test the states rather than the screens — empty, partial, expired session, refused permission, no network — and the awkward inputs: long names, non-Latin scripts, duplicate submissions, timezone edges. Regression runs before every release candidate. Accessibility checks cover keyboard traversal, focus order, contrast and screen-reader labelling. Sign-off is a named person accepting a specific build, in writing.

    You receive

    • A written test matrix: devices, OS versions, browsers and viewport sizes covered
    • A defect log with severity, reproduction steps and current status
    • Accessibility check notes covering keyboard, focus, contrast and labelling
    • A release candidate with written sign-off recorded against a specific build number

    Your part

    • Nominate who signs off, and give that person time to actually test
    • Supply the real-world data and awkward cases only your business knows about
    • Decide which defects block release and which ship as known issues
  7. Delivery

    Analytics instrumentation

    Implement and verify the measurement that every later decision about spend and product depends on.

    This is the stage that most often gets skipped, and skipping it is why stages 09 and 10 later run on opinion. Events from the model agreed in stage 02 are implemented alongside the features that emit them, then verified in a debug view event by event — name, parameters, value, and that it fires once rather than three times. Conversions are exported to the ad platforms and checked end to end. Instrumentation added after launch only ever describes a product that has already changed.

    You receive

    • Every event in the model implemented and verified individually in a debug environment
    • Conversion and value signals exported to the ad platforms, tested from click through to conversion
    • A written event map: what fires, where, with which parameters, and who reads it
    • Reporting views that connect spend to in-product behaviour rather than to installs alone

    Your part

    • Ownership of the analytics, tag manager and ad accounts, with us added as users
    • Agreement on what counts as a conversion and what one is worth to the business
    • Consent and privacy decisions signed off before events go live
  8. Delivery

    Launch

    Release to production or the stores with monitoring, halt criteria and a way back in place.

    Deployment or store submission happens against a checklist rather than from memory: signing and certificates under your ownership, declarations that match what the build actually collects, listing assets at current sizes, and DNS, certificates and redirects verified for web. Error reporting, uptime monitoring and the key funnel events are watched from the first hour, against the previous version where there is one. Staged rollout is used where the platform allows it, and halt criteria are agreed in writing before submission, not argued about afterwards.

    You receive

    • Production deployment or store submission, with signing and build reproducibility under your ownership
    • Crash, error and uptime monitoring reporting somewhere a person actually reads
    • A rollback or staged-rollout plan with written halt criteria
    • A launch-day watch list: the metrics checked, by whom, and for how long

    Your part

    • Ownership of domains, hosting, store and cloud accounts before launch day
    • Availability of a decision-maker during the release window
    • Approval of the final listing copy, legal pages and support contact route
  9. Growth

    Acquisition

    Buy demand against the product signals installed in stage 07, not against platform defaults.

    Account structure, geography, creative sets and bidding are chosen so the platform learns from clean signal and so tests stay separable when budget rises. Campaigns optimise toward the conversions and values built in stage 07 rather than toward installs or form fills that mean nothing downstream. Budget starts small enough to be wrong cheaply and moves on evidence. We say plainly when spend is too thin to support a conclusion, and when the honest answer is that the funnel, not the campaign, is the problem.

    You receive

    • Campaign architecture mapped to product events and value, documented with its assumptions
    • A creative and audience test plan with a defined read-out point per test
    • Conversion tracking verified inside accounts you own
    • A regular written read: what moved, what did not, and what is still unknown

    Your part

    • Ownership of the ad accounts, billing profiles and the platform business accounts they sit under
    • A media budget confirmed in advance, paid to the platform rather than to us
    • Brand and claims approval for creative, including anything regulated
  10. Growth

    Optimisation

    Change whatever the evidence points at, whether it sits in the campaign, the data or the product.

    A poor return is often not an ad-account problem. It can be an onboarding step that quietly loses new users, a payment failure on one card type, an API call slow enough to abandon, or an event firing on the wrong screen. Because the product, the data pipeline and the campaign sit with the same supplier, the fix is made where it will work rather than where the contract happens to allow. Changes carry before-and-after measurement, and abandoned tests are recorded so nobody repeats them next quarter.

    You receive

    • A prioritised change list spanning product, data and campaign, with the expected effect stated
    • Implemented changes with before-and-after measurement attached
    • A record of retired tests and abandoned ideas, with the reason each was dropped
    • Updated reporting whenever the event model changes underneath it

    Your part

    • Willingness to change the product when the data points there, not only the ads
    • A single forum where product and marketing decisions are made together
    • Enough runway for a test to reach a readable result before it is judged
  11. Continuity

    Ongoing support

    Keep the thing running, patched and understood after the launch attention has moved on.

    Software decays without anyone touching it: certificates expire, SDKs are deprecated, platform policies change, an OS release breaks a screen that had worked since launch. Support covers monitoring that someone reads, dependency and platform updates, incident response with an agreed route to reach us, and small changes that would otherwise queue behind a project. Scope, response expectations and what falls outside them are written into the agreement rather than assumed. Documentation is kept current so leaving us is never a technical problem.

    You receive

    • A support agreement stating scope, response expectations and exclusions
    • Dependency, platform and security updates applied on a stated cadence
    • Monitoring and alerting routed to someone who acts on it
    • Current documentation and handover notes, kept usable by whoever comes next

    Your part

    • A named contact on your side who can authorise urgent changes
    • Continued ownership of accounts, billing and renewals for third-party services
    • Early notice of business changes — campaigns, seasons, migrations — that affect load
Engagement models

How engagements are shaped

Four shapes cover almost everything we do, and which one fits depends on how well the problem is defined rather than on how large it is. Specific rates, milestones and payment terms live in the proposal and the service agreement, not on a web page.

01Fixed-scope project
Suited to work whose boundaries can be written down honestly: a defined build, a migration, an integration, a rebuild of something that already exists. Scope, acceptance criteria and milestones are agreed before the first invoice, and changes go through a written change request rather than an implied favour. Commercial terms sit in the proposal.
02Phased delivery
For work where later stages genuinely depend on what earlier ones find. Each phase is scoped, priced and approved on its own, with a decision point at the end where continuing is a choice rather than a default. It costs slightly more in overhead and saves considerably more in work that would have been built on a wrong assumption.
03Ongoing retained engineering
A recurring commitment of capacity for products that keep evolving: a backlog worked in priority order, maintenance, incident response and the small changes that never justify a project. Priorities are reset at an agreed cadence and the work in flight is visible throughout. The rate, the notice period and what is excluded are set out in the service agreement.
04Advertising management, media spend separate
Campaign management is charged as a management fee. Media spend is paid by you, directly to the platform, on your own billing profile — it is never our revenue and it never passes through us. That keeps the incentive to increase budget out of the relationship and keeps the account, the history and the data yours if we stop working together.
Held constant

What stays constant

These do not change with the size of the engagement, the stage it happens to be in, or how much anyone is in a hurry.

Measurement is defined before spend
No budget goes to a platform until we can see the conversion arriving from a click, with the value attached. Buying traffic against an untested event produces numbers that look like performance and mean nothing. If the tracking cannot be verified end to end, the honest step is to fix that first, even when it delays the launch date.
Scope is written down before it is invoiced
Every engagement starts from a document naming what is included, what is excluded and how a change becomes a change. Verbal scope is not scope; it is two people remembering a conversation differently three months later. When something genuinely new is needed mid-project, it is priced and agreed in writing rather than absorbed silently or resented quietly.
Access and ownership stay with you
Repositories, cloud projects, domains, analytics properties, ad accounts and signing keys are created under your ownership, with us added as members. Nothing is held as leverage and nothing is registered in our name for convenience. If the relationship ends on a Friday, everything you need still works on the Monday without us.
One contactable person who knows the code
You deal with someone who has actually read the repository, not a relay who forwards questions and returns paraphrases. It means answers are specific and occasionally inconvenient, and it means nobody can quietly lose a decision between two conversations. The escalation route and response expectations are written into the agreement rather than left to goodwill.
Work is visible while it happens
Commits land in your repository as they are written, builds go to a test track or preview URL as slices finish, and campaign changes are made in accounts you can open yourself. There is no reveal at the end. A project you can watch is a project you can correct early, which is the only cheap moment to correct one.
We say no to work that should not be built
Some requests are better answered by a spreadsheet, an existing product, or nothing at all. Others are technically possible and commercially unwise, and a few would put your ad or developer account at risk. We will explain the reasoning and decline, because taking the money and building it anyway is a worse outcome for both sides.
Questions

What people ask about working this way

01What happens when a project runs over?

We tell you as soon as we know, not at the deadline. Then we separate the causes: work that was underestimated is ours to absorb within the agreed fee, and work that grew because scope changed is priced as a change request you approve or decline. If the overrun is structural rather than a slip, the honest conversation is about cutting scope to a releasable core, and we will propose which parts to drop.

02Who owns the code, the accounts and the data?

You do, from the first commit rather than from final payment. Code lives in your repository, cloud projects and domains are registered in your name, analytics properties and ad accounts are created under your ownership with us added as members, and signing keys are yours. There is no proprietary framework you would have to keep licensing from us, and no build step that only works on a machine we control.

03What if we want to leave mid-project?

The agreement sets out notice and what is payable for work completed, and we will not make the exit difficult. Practically, you already hold the repository, the accounts and the credentials, so nothing needs to be released. We write a handover note covering where things stand, what was decided and why, and the known traps in the code. A supplier who makes leaving painful has usually stopped earning the work.

04Can you take over a codebase someone else wrote?

Often, yes, but not blind. We start with a short paid assessment: build it from a clean checkout, read the data layer, check what tests exist, list the dependencies that are unmaintained or about to break, and find where the secrets are hiding. That produces an honest view of whether the sensible route is to continue, refactor in place, or rebuild the parts that keep failing. Sometimes the answer is uncomfortable.

05Do you work alongside an in-house team?

Yes, and it works best when the split is written down: who owns which modules, who reviews what, whose conventions win, and where the boundary sits when something breaks at three in the morning. We are comfortable owning one part of the system while your people hold the rest, and comfortable handing work back when you have hired for it. What does not work is both sides quietly redesigning the same thing.

06What do you actually need from us?

Three things, mostly. One person who can decide without convening a committee, and who is reachable within a working day when a slice is blocked. Access early rather than eventually: repositories, analytics, ad accounts, sandbox credentials for anything we must integrate with. And a willingness to write things down — scope, sign-off, the awkward business rule that only exists in someone's head. Projects rarely stall on engineering; they stall waiting for a decision.

07What makes a project go badly?

Undefined success, in almost every case. If nobody can say what the thing is meant to change, every review becomes taste and every decision reopens. After that: scope agreed verbally, a decision-maker who is never available, measurement postponed until after launch, and a request to start building before stage 03 is settled. All four are visible long before a deadline is, which is why we raise them at the start rather than in the post-mortem.

Next step

Tell us where the project actually is

Send the shape of the problem, what already exists and where it is stuck. We will tell you which stages apply, which ones you can skip, and what we would do in the first two weeks.

Talk through your projectSee all capabilities

Directcontact@mnfinfotech.com