How we work

A clear sequence. Visible progress.

Three engagement models, one delivery rhythm. The model changes with the outcome; the review points and written decisions stay consistent.

01

Three ways to work with us

Discovery Sprint

You need to test a product direction, clarify a workflow or reduce uncertainty before committing to a build.

Duration
2–3 weeks
What you get
  • Opportunity brief
  • Workflow findings
  • Success measures
  • Clickable prototype
  • Technical proof
  • Delivery roadmap
What we need from you
Access to decision owners, current materials, analytics and system context.
Review cadence
Weekly working session, with a written review at the end of each week.
Next decision
Approve a build scope, test one assumption further, or stop.
Commercial shape
Fixed fee, agreed before the sprint starts

Product Build

You have a defined product or application to take from prototype to production.

Duration
3–6 months, released every two weeks
What you get
  • Dedicated team
  • Working software each sprint
  • Quality evidence
  • Production releases
  • Architecture ownership
What we need from you
A named product owner, access to systems and a review cadence that supports two-week increments.
Review cadence
Sprint review every two weeks, with a weekly written update.
Next decision
Continue, change scope, or move to handover.
Commercial shape
Monthly team fee, scoped per increment

Embedded Engineering

You need additional engineering capacity inside a team you already have.

Duration
Rolling monthly, three months recommended
What you get
  • Engineers inside your team
  • Your tools and standups
  • Code review and mentoring
  • Handover documentation
What we need from you
Your tools, backlog and a delivery lead who can set priorities.
Review cadence
Your existing sprint cadence, plus a monthly delivery review.
Next decision
Renew monthly, adjust capacity, or end with a written handover.
Commercial shape
Per-person monthly rate

The same sequence runs inside every engagement. Only the depth changes. Not sure which fits? Ask us →

02

The delivery sequence

01

Discover

What needs to change, and why now?

Align on the business case, users, constraints, systems, data and the decisions that matter.

  • Opportunity brief
  • Workflow findings
  • Success measures
02

De-risk

Which assumptions must we prove first?

Prototype the critical experience and test architecture assumptions before committing to a larger build.

  • Experience prototype
  • Technical proof
  • Delivery roadmap
03

Engineer

How do we turn the plan into progress?

Ship in reviewable increments with product, design, platform, data and AI work coordinated around one plan.

  • Production releases
  • Quality evidence
  • Delivery visibility
04

Scale

What will the next stage need?

Strengthen security, reliability, observability, performance and adoption as usage and complexity grow.

  • Platform roadmap
  • Operating visibility
  • Adoption insights
03

What we need from you

A decision owner

One person who can say yes, so work does not stall waiting for consensus.

Access

Repositories, environments, analytics and existing documentation.

Availability

One review call a week, and async decisions within two days.

Context

Current constraints, previous attempts and what did not work.

Early feedback

Direct feedback before a sprint closes, while it can still change the outcome.

04

How communication works

RitualFrequencyFormat
Sprint reviewEvery two weeksLive walkthrough with a recording you can share
Written updateWeeklyDone, next, and the risks that need a decision
Decision logContinuousOne shared document: what was decided, when, and why
EscalationSame dayDirect contact with the engagement lead
05

Quality and risk

  • Tests prioritized around the paths that carry money or customer trust.
  • Staged rollouts with a written rollback plan before each cutover.
  • Security review before production data is accessed.
  • Documented decisions so your team can continue without us.
06

Commercial basics

  • Fixed-scope discovery, or a monthly team agreement.
  • Change control: new scope gets a written estimate before work starts.
  • Invoicing monthly in advance for team models, milestone-based for fixed scope.
  • Mutual NDA and custom agreements supported.
07

Questions teams ask before starting

Can you work with our existing product and engineering team?

Yes. Embedded engineering places people inside your team, using your tools, standups and review process. We can own a defined product stream or work alongside internal owners.

Do you work fixed price or time and materials?

Discovery is fixed price with a defined deliverable set. Product builds run as a monthly team fee with increments agreed before each sprint, which keeps scope and operating cost honest on both sides.

How quickly can you start?

Start dates depend on team availability and the access we need. We confirm a date and the first review point before work begins.

What if we already have designs or a legacy system to migrate?

That is fine. We review existing designs, code, data models and integration dependencies against your workflows, then plan staged engineering, migration validation and delivery.

Do you sign NDAs?

Yes, a mutual NDA is standard before detailed discussions. We can also work under your own agreement.

Who owns the code, decisions, and post-launch maintenance?

You own the code, documentation, and infrastructure. Decisions and runbooks are documented so ownership transfers cleanly to your team, or we can continue supporting maintenance and product evolution under a defined agreement.

Tell us what you need to build or change, and we will suggest the right shape.

Discuss your projectMore about ProwebXTrust & working model