Eclipse Holdings Group Eclipse Holdings Group

DELIVERY PROCESS

We build the app. You watch it ship.

This page exists so that nobody signs off on a project without knowing what the next few months look like. It describes the sequence we follow at Eclipse Holdings Group, what you get at each stage, and where your input is genuinely needed rather than politely requested.

Book a scoping conversation See what we build
A drafting window frame drawn on a worktop, its interior ruled into four columns with one amber indicator lit at the top-left corner.

One window, held open

The same release window runs through the whole project — from the first scoping call to the store submission. Everything below is what travels under it.

Where it starts

Scoping: two to four weeks before any code

Scoping produces a written document: what the product does, who uses it, what the main flows are, and what is explicitly out of scope for the first release. We also produce a screen inventory and a build sequence.

Your input here is decisive, particularly about the exceptions and edge cases that people usually describe as "obvious". They are rarely obvious to anyone outside your organisation.

What scoping hands over

  • The product brief

    A written statement of what the product does, who uses it, what the main flows are, and what is explicitly left out of the first release.

  • Screen inventory

    Every screen the first release will contain, with its purpose written in one sentence. Fewer screens than you expect at this stage, on purpose.

  • Build sequence

    The order sprints arrive in, and which of them produces a build you can actually install and test against.

  • Out-of-scope list

    Named explicitly, so a requirement that arrives in month three has something to be measured against rather than argued about.

UI/UX and handoff

Wireframes, prototype, then visuals — and states defined before build

Each row below is one thing the design stage hands to development, and why it matters when the build starts.

Structure

Wireframes first

Structure and navigation with no visual styling applied. If the wireframe does not make the product obvious, no amount of visual polish will.
Prototype

A clickable walk-through

The main flows become something you click through yourself, before a developer writes a line of production code. Feedback is easier when you can feel it.
Visuals

Design follows the structure

Colour, type, spacing, motion. Only after this step do screens go to build, so visual decisions never overwrite a flow that already works.
Localisation

Second language, designed in

For multilingual products, the second language gets designed at this stage. Retrofitting it later costs more than planning for it.
States

Empty, loading, error, offline

Every screen is handed over with its states defined, including what happens when a user has no permission for an action. Unglamorous work that saves arguments later.

When a developer has to invent the error state, the result is usually a red toast and a vague message. Defining it in design takes ten minutes and prevents a complaint in month six.

Sprint rhythm

What lands every two weeks

Development runs in two-week sprints. Each one ends with an installable build, a short note on what changed, and a list of what is next. Test builds run against a test database with realistic data rather than placeholder screens.

Release window — holds while sprints scroll past
Two-week cadence

The point of the cadence is that you always know where the product stands. You keep the build and can show it to colleagues inside your own organisation, which usually produces better feedback than a meeting does. If you disappear for a month, the project either stalls or starts guessing — and guessing is expensive.

Kickoff

Sprint starts

  • Scope of the sprint written down
  • Open questions raised early
  • Your one review call scheduled

Build

Working increment

  • Feature work against test data
  • Unit tests for business rules
  • Automated UI runs on flows

Testing

Real handsets

  • Device matrix via Firebase Test Lab
  • Keyboard open, slow connection
  • Battery nearly flat

Handover

Build you can install

  • Short note on what changed
  • List of what is next
  • Build stays with you between sprints

Testing and release

Automated runs, real handsets, and a pipeline that behaves the same way twice

Unit tests cover business rules, automated UI runs cover critical paths, and Firebase Test Lab covers the device matrix. Then someone uses it properly: with the keyboard open, on a slow connection, on a phone with the battery nearly flat.

The release pipeline is set up with Fastlane and GitHub Actions so that a release is a defined sequence of steps, including version numbering, build variants, store metadata and submission. It runs the same way every time, which is the entire point. Manual release steps are where late-night problems live, and app store submission is unforgiving about a missing certificate at the wrong moment.

Device testing

Firebase Test Lab

Runs the critical paths across the device matrix your users actually carry, not only the one phone on the desk.

Release automation

Fastlane and GitHub Actions

Version numbering, build variants, store metadata and submission, all as defined steps instead of a checklist somebody remembers.

Launch

A bug found before release is a normal cost of development — not a failure of the process.

Eclipse Holdings Group — delivery principle

Launch covers submission to the App Store and Play Store, including review feedback if a submission comes back with questions, plus the go-live checks for backend services, monitoring and access permissions. We plan for a review round rather than assuming a first-pass approval, so the calendar has room for it.

A review round is a normal step, not a failure to plan.

After launch

The first weeks in production

Sentry is connected before launch, not after the first complaint. In the weeks that follow, we watch error rates and usage patterns, and fix what surfaces. Real users find the paths nobody tested, and the first month of production data is the most useful input any project gets.

Monitoring

Sentry, from day one

Error rates, crash reports and usage patterns watched from before launch — not after the first complaint arrives.

Priorities

Fix what surfaces

Real users find paths nobody tested. What they hit first sets the priority order in the weeks after launch.

Cadence

Maintenance rhythm

Patching, dependency updates and store compliance handled on a schedule — see the support page for the full picture.

Handover

Your team stays in the loop

Code access, deployment permissions and infrastructure decisions get easier when your IT team has been in the room.

Before you sign off

Questions we get asked before a project starts

Three that come up most often. If yours is not here, ask it directly — an hour of conversation beats a week of guessing.

How much of my time does this require?

Scoping is the heaviest period, usually a few hours a week for the first month. During sprints, one review call per sprint plus time to try the build. If you disappear for a month, the project either stalls or starts guessing, and guessing is expensive.

What if the scope changes mid-project?

It will. We handle changes as explicit scope adjustments with a time impact, so you can decide whether the new requirement is worth the delay. Absorbing changes silently produces a project that finishes late with no clear reason why.

Do you work with our internal IT team?

Yes, and it is usually better when we do. Handover, code access, deployment permissions and infrastructure decisions all get easier when the people who will live with the system have been in the room.

Next step

Book a scoping conversation and get a delivery timeline back

Bring the problem, not the specification — that is what scoping is for. In return you get a written document, a screen inventory, a build sequence and an out-of-scope list you can hold us to.

Book a scoping conversation Ask about sprint cadence