A method worth anything works at any size.
We do not build websites. But when a friend's tutoring site needed a careful decision, the same input-management thinking we bring to enterprise transformation turned out to fit a project a thousand times smaller, without changing shape.
An independent language tutor needed a warmer registration page, but it ran on a single component that quietly did the real work of enrolling students.
Apply the same four-step method we use at enterprise scale: read the baseline, spend the smallest effective input, protect what works, test the exit.
A warmer front door with nothing new to maintain, the enrolment component preserved and verified, and a method proven at any size.
We do not build websites, and this case study is not an attempt to suggest otherwise. It is here for a simpler reason. A method is only worth anything if it holds when nobody important is watching, and Norbu is where ours did.
Norbu teaches Tibetan, independently, to students who find their way to a modest website. The site needed two ordinary things: navigation that worked for both newcomers and returning learners, and a registration page that felt like an invitation rather than an afterthought. Nothing about the brief announced itself as interesting. The interesting part, as is so often the case, was buried one layer down.
The registration page ran on a single component that did the actual work of enrolling a student. The tempting version of the job was to rebuild that page from scratch to make it look the part. We have sat through enough enterprise programmes to know the exact shape of that error. You redesign over a working core, the surface looks finished, and the function has quietly stopped. A handsome page that no longer lets anyone in. The scale was tiny; the failure mode was identical to ones that cost organisations millions.
So we did the small version of the thing we always do. We read the baseline first, establishing which component carried the function and what a redesign would have to keep alive. With that known, the work shrank. For the navigation, instead of reaching for another plugin or a slab of custom code, we used the builder's own display conditions, so a new visitor and a returning student each see the call to action meant for them, with nothing added to the stack. The smallest input that produces the effect, chosen on purpose over the showier option that bills you in maintenance later.
Where the redesign genuinely touched the functional core, we treated it like a cutover. Back up first. Preserve the working component rather than gamble on recreating it. Then test it from the outside, as a real new student would arrive at it, before declaring it done. The deliverable was never the prettier page. It was a working enrolment, handed over intact.
The smallest input that produces the effect, not the showier option that bills you in maintenance later.
It is, by any measure, a small project. We tell it because the smallness is the evidence. The lens does not change with the size of the decision, and a method that only performs for large clients is not a method, it is a sales line. We would rather steer by the front windscreen towards where we are going than by the rear-view mirror of what already exists, and that holds just as true for one teacher's website as for a balance sheet.
Read the baseline, spend the smallest effective input, protect what works, then test the exit. The discipline does not change with the size of the decision.
The same four moves we bring to a board apply to one teacher's website: read the baseline, spend the smallest input that does the job, protect what already works, and test the exit. The size of the decision never changes the discipline.
Facing something similar?
We help teams turn challenges like this into measurable outcomes.