Background
On April 11th, 2025, my sister Timberly asked me about a website for her tutoring business. She tutors four-to-eight-year-olds in reading and math, and most of her students come from other parents recommending her. She wanted something simple: a page about her, reviews from parents, and a pricing page.
Like the Set-Rite Plumbing project, this was family. I still wrote it up like any other client project, with a scope, a price (discounted for family), and a plan to build it in phases. I’ve found that family projects go better that way. When there’s no scope, there’s also no finish line, and the project stays open for a very long time.
The first phase was a minimum viable product, or MVP: the smallest version of the site that does the job. That meant a home page, an “Our Approach” page, pricing, and reviews. Online booking, a way for her to add reviews herself, and anything that needs a login would come later, once she knew what parents were actually asking for.
Objectives
The site had to do one thing well. When a parent hears about Ms. T from another parent, they will look her up before they email her. So the pages needed to answer the questions those parents have (how does she teach, what does it cost, and what do other families say) and give them an easy way to book a free trial.
I also wanted to try something new on the design side. I designed the site in Penpot, a design tool similar to Figma, and had the colors, spacing, and type sizes from that design generated directly into the code instead of retyping them by hand. If that worked, the design file and the finished site would always match, and any future color or spacing change would only need to be made in one place.
Challenges
Timberly’s parents look at this site on a phone, usually between school pickup and dinner. That set the priorities: mobile first, quick to load, and readable in whatever light they’re sitting in. Light and dark modes both had to look designed, not like one was an afterthought.
Reviews were the hardest content problem. A word-of-mouth business needs them, but the reviews came in as emails and texts from parents, a few at a time, in the weeks after the site was already live. I needed a way to add them without a database, a login, or a content management system I’d have to maintain, and a reviews page that would still work when there were thirty of them.
Then there was hosting. I build the site with an automated pipeline, but it’s published from a second copy of the project on a different host. Two hosts were reading the same set of build instructions, and some of those instructions only made sense on one of them.
Solutions
The site is a static site, meaning it’s built once into plain web pages rather than assembled by a server on every visit. There is no application server to patch, and it loads quickly on a phone. Images are automatically resized for the screen they’re being viewed on, so the large hero photo doesn’t slow things down.
The design-to-code idea worked. The colors, spacing, and type sizes come straight from the Penpot design, and everything on the site is built from that one set of values. Light and dark mode is the same layout with a different set of colors swapped in.
For reviews, I kept it simple: each review (the parent’s name, a date, a star rating, and the text) is stored right in the project files. The reviews page splits them into pages automatically, and the pricing page shows one review in a banner, so a parent reading the rates also sees a real family vouching for her. Adding a review is a small edit that I publish. It isn’t fancy, but there is nothing to break, and when Timberly texts me a new one, it’s about a five-minute change.
Pricing is four cards: two tutoring rates (weekday and weekend, per thirty minutes) and two add-ons, plus a list of what’s included with any plan, like Zoom or Google Meet, extra materials by email, and a conference every three months. The referral incentive (a free fifteen-minute mini-lesson for every family you send her) went on that page too, since referrals are how she gets students.
The two-host build problem came down to two small guard rules that tell the second host to skip the instructions it can’t use. It’s the same set of instructions on both hosts; only one of them does any work.
The first phase (design, build, the mobile pass, and light and dark modes) wrapped up on May 14th, 2025, about five weeks after that first conversation. Reviews from three families came in over the next two weeks.
Results
The site does what we scoped it to do. A parent who hears about Ms. T can read what other parents say, see exactly what a session costs, and book a free trial from their phone. It’s live at learningwithmst.com. Traffic looks like what you’d expect for a referral business: mostly direct visits, with Google starting to send a few. I lost the analytics for the launch window to a storage failure on my end, so I don’t have launch numbers to share. That one’s on me, not her.
The bigger result for me was the design-to-code pipeline. This was the first project where the design values went straight from the design tool into the site without me retyping anything, and it’s the pattern I’ve kept using in my design-system work since.
Lessons Learned
- Design-to-code works, but keep the build quiet. The first time the design values were generated into code, the tool reported 61 warnings about duplicate names. They were harmless, but a wall of warnings on every build is the kind of noise you learn to ignore, and then you miss the one that matters. Next time I’ll clean up the design export so the build stays quiet.
- Reviews as content, not a system. I had set up the groundwork for a phase-two review dashboard (a database and a login), then never used it. Storing the reviews in the project files was the right call for the MVP. The unused groundwork is a reminder to build the second phase when the second phase actually arrives.
- One set of build instructions, two hosts, two guards. The two guard rules are evaluated at different stages, so adding only one of them still broke the second host. I learned that the slow way, one failed build at a time.