01 Los Angeles, California
Software your customers finish, and systems your team trusts.
Two problems, one team. We build the product the public uses and the platform your staff runs on.
Deliverables, dates, and fees in writing before anything substantive begins.
Whoever scopes the work stays on it. No handover to people you have not met.
Notes, source material, and walkthrough. Never a separate line item.
Consumer — software the public relies on
Business — the platforms organisations operate on
01 Services
Three services. One outcome each.
Most engagements use two.
01
Consumer products
People finish what they start
Apps and web products people use without being taught.
- Sign up that people complete
- Payments that recover from failure
- Works on the phones your customers own
- Tested on real users before build
02
Business systems
One system, not five
The platform your staff runs on, fitted to what you already have.
- One place to enter data, not three
- Numbers both teams agree on
- Reports that build themselves
- Off the system nobody can maintain
03
Product strategy
A costed answer
What to build, what to buy, what to leave alone.
- A costed answer, not an opinion
- The order that makes change stick
- Where your time is actually going
- Told plainly when to build nothing
02 Who this is for
Two problems. Both ours.
If one of these is your week, we are the right call.
Your product loses people
- Users quit at sign upThey finish it
- It buckles at peakIt holds
- Support answers the same question all dayThe screen answers it
- Only works on new phonesWorks on what people own
Your systems disagree
- Same data typed into two placesEntered once
- Two teams, two different numbersOne agreed figure
- Reports take someone a dayThey arrive on their own
- One system nobody dares touchAnyone on your team can
03 The written scope
What you receive before work starts.
You get this before anyone starts. Ten items, signed by both sides.
Why this matters to you
Item 03 is the one clients never get. Naming what is excluded is how you find out on day one, not month three, that you pictured different work.
Item 07 means a change is a decision with a price on it, not something that quietly happens to your timeline.
Item 08 settles who owns the code before anyone writes it.
04 How a project runs
Written down before the first stage ends.
01
Conversation
No charge
What you are after, what is already in place, and how you will judge whether it worked. No obligation either way.
02
Written scope
Signed first
Deliverables, dates, fees, ownership, and an explicit list of what sits outside the job.
03
Build in visible pieces
Reviewed as it lands
Something running at each checkpoint rather than a percentage in a status email.
04
Handover
Documented
Notes, source material, and enough walkthrough that your own people can carry it from here.
The work we turn down.
Stated openly, because the circumstance arises often enough to warrant it and because few practices are willing to publish it.
When the problem is upstream of software
Many problems arrive framed as software and resolve into disagreement. Two teams defining the same number differently. Building on that raises the cost of fixing it.
When something adequate already exists
Where the workload is standard and the market mature, buying is the better answer and we will say so.
When the timeline cannot hold the scope
If a date is fixed and the work will not fit, we say so before signing rather than in month three.
07 Questions
Asked before the first call.
What kind of software do you take on?
How does a project start?
Who owns the software you make?
What happens once it is live?
A problem you can articulate in a paragraph is enough to begin.
Tell us what needs doing and roughly when. We will say early if the work is not a fit for us.