The Build · the method
The product is the method.
Most studios sell hours. I sell a process. The Build is one named, repeatable way of working that I run identically whether you need a booking app, a clinic site, or an internal tool. The range is real because the rigor never changes.
Five phases. You always know which one we are in, what comes out of it, and what happens next.
Why this exists
Breadth is only trustworthy when it rides on a system.
“I do everything” is what an amateur says. “I run the same five phases on everything” is what a senior operator says. One brain holds the whole project, so nothing falls in the gap between a designer, a developer, and a project manager: there is no gap, because there are no handoffs.
The five phases
Map, Shape, Make, Prove, Hand-off.
Map
Get the real problem on the table.
We sit down and pull the fuzzy brief apart until the actual problem is visible. Who is this for, what has to be true on launch day, what is explicitly out of scope. I write the brief back to you in plain language so we both agree on the same thing before a single screen exists.
- What you get
- A short, proposal-grade scope: the problem stated clearly, the must-haves, the won't-dos, and a fixed price and date you can plan around.
- Rough duration
- A few days to a week
One concrete detail
The won't-do list is as important as the to-do list. Naming what we are not building on day one is how a project finishes on the date I promise.
Shape
Decide how it looks and flows before it is expensive to change.
I design the screens and the flow: how a customer books, how the owner runs their day, where the money moves. We resolve the hard decisions on paper and in clickable layouts, where changing your mind costs minutes, not weeks of rebuilt code.
- What you get
- Clickable screens for the core flows plus the few decisions that actually shape the build, written down so nothing is left to assumption.
- Rough duration
- One to two weeks
One concrete detail
I bring the awkward questions early: what happens when two people book the same slot, what the owner sees at 9pm, what a no-show does to the deposit. Edge cases decided now are not surprises later.
Make
Build the real thing, in the open.
I build it: the real product, on real infrastructure, with PromptPay and LINE wired in where the vertical needs them. You see working software at the end of each stretch, not a status update. Bangkok hours, one person on the keyboard, no telephone game between roles.
- What you get
- The working product taking shape on a private link you can open any time, plus regular check-ins where you click the real thing, not a mockup.
- Rough duration
- Two to six weeks, depending on scope
One concrete detail
It is built bilingual from the first line, not translated at the end. Thai and English are first-class, and the font stack and copy switch with the language.
Prove
Break it on purpose, so reality can't.
Before anyone real touches it, I do. I run the messy paths: bad inputs, double bookings, a deposit that half-fails, slow phones on Thai mobile networks. I fix what breaks and tune what is slow, so launch day is boring in the best way.
- What you get
- A product that has survived the rough use it will get in the wild, plus a clear note on what was tested and what is intentionally out of scope.
- Rough duration
- A few days to a week
One concrete detail
I test on a mid-range Android over mobile data, not just on a fast laptop. If it is slow on the phone your customer actually owns, it is not finished.
Hand-off
You get the keys, not a dependency.
Everything lands in your name: the code, the hosting, the domain, the accounts. I walk you through running it and leave a plain-language runbook so a normal human, not just a developer, can keep it going. If you ever want someone else to take over, they can read it and pick it up.
- What you get
- Full ownership of the code, hosting, domain, and accounts, plus a runbook in plain language for the day-to-day and the what-ifs.
- Rough duration
- A day or two, plus a settling-in window
One concrete detail
No lock-in by design. The login is yours, the bill comes to you, and nothing breaks if you stop working with me. That is the point.
Why it works for anything
Same five phases, any kind of product.
A gym booking app, a clinic site, and an internal stock tool look nothing alike on the surface. Underneath, they are the same job: get the real problem on the table, shape it, make it, prove it, hand it over. The phases do not change with the vertical, which is exactly why the breadth is safe to trust.
The same path, three different problems
A booking app turns “are you free?” into a paid slot without you touching your phone.
A bilingual site earns the click and the call, and shows up when someone searches in Thai.
An internal tool retires the spreadsheet and the group chat your operation quietly runs on.
Start at Map
Tell me the problem in plain language.
The first phase is a conversation, not an invoice. Send me the fuzzy version and I will write it back to you as a clear scope with a fixed price and date.