Featured Work · Client Build
LIVEFrogs Leap Solutions. Live in 31 days, and still running.
A plumbing company in Eugene, Oregon. Empty repo on July 17, live site on August 17. 20 service pages, 4 town pages, and a lead form that lands in a real inbox. I built it, and I still run it.
Context
Dawn ran a Roto-Rooter operation before this. Frogs Leap is the company she left to start. Her plumbing experience goes back to 2008, and the company does not, which is a distinction the site is careful about everywhere it comes up.
So this was never a business with a website problem. It was a brand new company with no customers, no reviews, and no search presence at all. Nothing to inherit. The site isn't replacing word of mouth, it's the front door for a company starting at zero.
Which makes the job specific. Not "make a website." Make the phone ring, and keep it ringing after I stop paying attention. Those are different projects. The second one is the one people get wrong.
Marco Leon designed it. He's a graphic designer who was new to code when we started, so the build doubled as his first real consulting engagement. He worked in Figma, judged every screen with a designer's eye, and I coached the engineering.
Approach
Same system I run for real estate agents, pointed at a different trade. Nothing about it was bespoke.
Stack:
- · Next.js App Router · TypeScript · Tailwind
- · Vercel for hosting, git integration as the pipeline
- · Resend for lead email
- · No database, no CMS, no auth
Calls that mattered:
- She owns everything, from day one. Domain, hosting, and email account are all in Dawn's name. Nothing's locked to me. A care plan people can leave is the only kind worth selling.
- One source of truth for the business facts. Name, address, phone, and hours live in a single typed file. Header, footer, and structured data all read from it. Local search punishes a phone number that disagrees with itself, and this makes that impossible.
- Server components by default. The lead form is the only interactive island on the site. That's the whole performance strategy, and it holds up without anyone tuning it later.
- A town gets a page when it has something to say. Town pages are opted in by real local content, not by being listed in a config. 4 pages that actually differ beat 40 that don't, and Google agrees.
- No fake reviews. Ever. The reviews file ships empty on purpose, and the site emits no rating markup until Dawn has real ones. Invented review schema is a manual penalty, and plenty of agencies do it anyway.
What's on it:
- 20 service pages. Residential and commercial, from water heaters to hydro jetting to grease traps. Each one generated from typed content, so a missing field breaks the build instead of the page.
- 4 town pages. Springfield, Junction City, Veneta, and Cottage Grove. Eugene is the homepage, because two pages competing for one town is a self-inflicted wound.
- A hardened lead form. Validation runs server side, not in the browser. Honeypot field, a minimum fill time that kills instant bot submits, and replies route straight back to the customer.
- Structured data. Plumber, Service, and breadcrumb markup, all fed from that same business-facts file.
- 6 guards that run on every pull request. Copy style, button behavior, layout, design tokens, and a ship-blocker check that fails the build if placeholder content or a stock photo tries to reach production.
Outcome
Live and indexable on August 17, one day inside the deadline we set at kickoff. The lead form was tested end to end on a real submit before launch, and routing to Dawn's inbox is verified working.
I'm not going to quote you a traffic number or a lead count. Those belong in the monthly report, where they can be read in context, instead of on a marketing page where they exist to impress you. What I'll claim here is what I can prove. The site is up, it's fast, it's crawlable, and the leads arrive.
What's next
A care plan that only keeps the lights on isn't worth paying for. This is what's queued.
- ServiceTitan. Frogs Leap dispatches on ServiceTitan, and the site already carries the exact opt-in language its text registration requires. Wiring the two together is next: booking that writes to the real dispatch calendar instead of a form that emails someone, and review requests firing automatically off a completed job.
- Google Business Profile, and the first reviews. Reviews are Dawn's number one metric, and the map pack is where local search is actually won. The site is the easy half of that.
- Measurement, then a monthly report. Calls and form submits tracked as separate conversions, and tagged links everywhere we control one, so "Google found us" splits into which Google. Every report ends with one recommended action. Otherwise it's just numbers.
- The pages that aren't written. The industrial services, and an About page that tells Dawn's story rather than the company's.
- A second metro. Redmond is 130 miles away and needs its own profile and its own cluster of pages. The URL namespace was reserved for that on day one, so it's additive instead of a rebuild.
Reflection
Content is the bottleneck, not code. I had pages ready and waiting on photos, service details, and license numbers. If I ran it again I'd start collecting that in week 1 and treat it like a deliverable with a due date, not something that shows up when it shows up.
The guards earned their keep. Every check in that repo exists because something already went wrong once. A rule you write down after the fact is a preference. A rule that fails the build is a rule. Most of what a care plan actually buys you is the second kind.
Plumbing isn't real estate, and that turned out to be the point. The same build works for any local business that needs to get found and needs the phone to ring. Different words, same machine.
Live at frogsleapsolutions.com. If you're an agent who wants the same thing pointed at real estate, here's what that costs.