Project File / 08 / Productized service
I put a two-hour deadline on custom web design
One custom conversion page, a fixed price, and a written start time turned a vague service into a product with edges.
Custom website work often begins with a tiny request and immediately expands into discovery, copy, design systems, integrations, content migration, and a month of feedback. The uncertainty is expensive for everyone.
SITE/120 asks a narrower question: what if the product is one excellent page, delivered as a hosted preview and source repository within 120 minutes of a written start? The constraint makes the sales page louder. More importantly, it makes the operating rules clearer.
08.01
The constraint is the product
The offer is one custom page for one primary conversion goal. It can send someone to an existing booking system, quote form, phone number, location, or other official destination. It is not a compressed five-page website, ecommerce build, custom application, or brand strategy engagement.
That line protects the quality of the page and the credibility of the timer. If the scope cannot fit, the honest answer is a different project, not faster typing.
Offer boundaryOne page, one primary action, one review path.
08.02
The timer starts after the ambiguity ends
Submitting the intake does not start the clock. SITE/120 first confirms scope, price, availability, required access, payment, the timestamped start, and the delivery deadline in writing.
DNS propagation, private integrations, and missing merchant credentials do not become fake successes just because a timer is running. The live page names those dependencies instead of burying them in terms nobody reads.
08.03
The intake refuses to pretend it sent anything
The form prepares a local email draft. It explicitly says that nothing has been received until the person reviews the draft and presses Send in their mail app. It also tells people not to include passwords, API keys, card details, or DNS credentials.
That is less seamless than a hidden form endpoint, but it is transparent, resilient, and appropriate for the current volume. The first operational system does not need to cosplay as enterprise software.
Current handoffA prepared email draft, not an invisible submission claim.
08.04
A live offer is not proof of demand
The site, build system, pricing, intake, and delivery rules are live. That does not mean the service has proven a repeatable customer channel or that every business can be served inside the constraint.
The current V2 preview also still declares the older Beryl deployment as canonical. That release split needs cleaning before serious distribution. After that, the useful evidence is a run of paid projects, each timed from clean intake to verified preview, with the exceptions recorded instead of explained away.
What survived
Three things I would carry into the next build
- A deadline is credible only when the starting conditions are explicit.
- Productized services become stronger when exclusions are part of the interface.
- Do not mistake a finished offer for validated demand.