CrossX

How we work

A delivery process built to remove surprises.

Short feedback loops, working software early, and decisions made by the people doing the work. Here's what working with CrossX looks like from first call to handover.

  • Working software early
  • Visible progress every week
  • Built to be handed over

Operating principles

Four rules we don't bend.

  1. Problem before solution

    We start with the outcome you need and the constraints you have — not with a technology we want to use.

  2. Thin slices, early

    We ship a narrow, real slice end to end before widening it. Risk shows up in week two, not month six.

  3. Decisions in the open

    Architecture choices and trade-offs are written down, with the reasoning, where your team can see and challenge them.

  4. Designed for handover

    Documentation, tests and runbooks are part of the work, not an extra. You should be able to run what we build without us.

Delivery phases

From first conversation to a system you own.

Phases overlap and repeat — this is a map, not a waterfall. Staff augmentation engagements follow your process instead; the same habits still apply.

  1. 01

    Discover

    We dig into the goal, the users, the existing systems and the constraints — budget, deadlines, compliance, team. We name the riskiest assumptions so we can test them first.

    • Problem statement
    • Constraints & risks
    • Success measures

  2. 02

    Shape

    We agree on scope for the first release, sketch the architecture, and plan a thin vertical slice that proves the hardest part works.

    • Release scope
    • Architecture sketch
    • Delivery plan

  3. 03

    Build

    Short iterations with working software at the end of each one. You see demos, not status reports, and you can change direction while it's still cheap.

    • Working increments
    • Automated tests
    • Regular demos

  4. 04

    Launch

    We harden for production — performance, security review, observability, rollback plans — and release in stages so real usage informs the next step.

    • Production release
    • Monitoring & alerts
    • Rollback plan

  5. 05

    Operate & hand over

    We stay through stabilization, then transfer ownership deliberately: walkthroughs, runbooks and pairing with your engineers. Or we keep running it, if that's what you need.

    • Runbooks & docs
    • Knowledge transfer
    • Support options

Engagement models

Pick the model that matches who owns the work.

The right model depends on how much direction you want to give and how much delivery you want us to carry. Toggle between them to compare.

Staff augmentation

Senior engineers join your team and work inside your process.

Day-to-day direction: Mostly you

Who manages day-to-day
You do. Our engineers join your standups, boards and code review.
Scope ownership
You own the roadmap and priorities. We own the quality of our engineers' work.
Best when
You have a working team and process and need more senior hands, fast.
Typical ramp-up
Usually the quickest start, because engineers slot into your existing setup.
How you scale
Add or release individual engineers as your roadmap changes.

Dedicated team

A stable, senior team focused on your product, led by us.

Day-to-day direction: Shared

Who manages day-to-day
A CrossX lead runs the team day to day and works closely with your product owner.
Scope ownership
You set direction and priorities. We plan and deliver the work to get there.
Best when
You need a whole capability, such as a platform or AI team, without hiring it first.
Typical ramp-up
A short setup period to form the team and agree ways of working.
How you scale
Grow or reshape the team as a unit, keeping its context and momentum.

Project delivery

We own a defined outcome from discovery to launch.

Day-to-day direction: Mostly CrossX

Who manages day-to-day
We do. You get regular demos and decisions, not task management.
Scope ownership
Agreed up front in a discovery phase, then managed through change as we learn.
Best when
The goal is clear, such as a new product or a migration, and you want one accountable team.
Typical ramp-up
Starts with discovery, so the build begins with a shared plan.
How you scale
Add phases or follow-on work once the first release is live.

Week to week

What you can expect from us.

  • A named lead

    One senior person accountable for delivery and for telling you the truth about it.

  • Visible progress

    Demos of working software and a written update you can forward to your stakeholders.

  • Your tools

    Work happens in your repositories, tracker and chat — no black-box portal.

  • Early warnings

    Risks and scope questions are raised the moment we see them, with options attached.

Next step

Let's map your project to a plan.

Tell us where you are today. We'll suggest a first phase and the smallest team that can deliver it.

Plan a first phase See our services