We build websites and automations for service businesses, and for design agencies too. This account is now the studio's, and we'll post what we learn doing it.
Starting point, for the record: domain rating 0, zero organic keywords. We'll share what moves it.
Partnering with a build team is useful when an agency already sells and designs, and needs someone who ships under their name.
You keep strategy, design and the client relationship. We build, test and launch. The site goes out as yours. That split works when the handoff is build-ready.
It is the wrong move when discovery is still fuzzy, the design is not approved, or three people on the client side can change scope without one approver. In those cases a build partner does not speed you up. You spend the project clarifying what should have been clear before development started.
A build-ready handoff usually includes the approved design across desktop, tablet and phone, final copy and assets, the stack decision, one named approver, and a written definition of done. Without that, a fixed scope turns soft the moment the first change request lands.
Fix the handoff first. A build partner helps you ship more under your brand. It cannot rescue an unclear brief.
Zim y Züm is a play café for families in Lima. Free play, workshops, birthdays and memberships each used to live in a different booking habit.
Before the platform, a lot of that flow sat in chat and in the heads of the team. It worked in office hours. A parent who wanted to book late in the evening had to wait. The business also struggled to keep one clear view of visits, events and payments.
With Surgente Studio on design, we defined the product and built it end to end. Families move through a public site in Spanish or English, book free play or birthday packages, and manage memberships and visit packages from their own account. Behind that, the team runs reservations, events, memberships, coupons and the front desk from one back office, including a point of sale for the café.
That is the kind of product work we like. One path for the customer. One place for the business. The design carries the warmth of the space. The system carries the daily load so the team is not stitching the day together from separate chats and spreadsheets.
SEO for a service site starts with a blunt check. Is the page you care about even in the index.
We still see launches where the blog is crawlable and the money page is blocked, marked noindex, or buried under a thin homepage that says almost nothing. Teams then ask why they are not ranking for the service they sell. The crawler never got a clean shot at the page that matters.
A practical pass looks like this. List the three pages that should bring work. Check each one in Search Console or with a site query. Confirm the URL returns 200, is not noindex, and is linked from the homepage or the main nav. If a service page only lives in a PDF or a buried footer link, fix that before you write another blog post.
Ranking talk comes after the page can be found. Content and links help a page that is already eligible. They do not rescue a page the search engine is not allowed to see. Fix crawl and index first. Then put your effort on the pages that pay the bills.
Building a Figma-like design tool in Rust, with Claude Code working inside it.
Fast to open, very light, and the agent works directly on the canvas.
Having the terminal right inside the design tool is the best part!
Fable 5.2 / Opus 5.5
A lead form without an owner is just a polite way to lose work.
We have watched teams celebrate a new form, then discover days later that messages were stacking in an address nobody checked. The site did its job. The business did not.
The smallest automation that usually pays off is boring on purpose. Route every inquiry to one named person. Set a reply window the team can keep. Log who answered and when. That is enough to stop the quiet leak.
Here is a simple version that works for many service businesses. Form submissions go to one inbox and one chat alert. A backup person is named for days off. The first reply is a short human note, not an auto sequence that pretends to know the project. Only after that first reply do you decide if the lead needs a call, a quote, or a polite no.
Fancy tools can wait until that part works on a quiet Friday. If the boring layer fails, a smarter stack will only hide the same problem behind more dashboards.
Most small businesses do not need a new website. They need the path from interest to a real reply to stop breaking.
We still walk through sites that look sharp on a laptop and fall apart the moment someone tries to write in. The offer is vague. The form sits behind three clicks. The message lands in a shared inbox nobody owns on Fridays. A redesign will not fix that.
Before we talk about new visuals, we ask one thing. Can a stranger understand what you do, trust it enough to write, and get an answer from a person who owns that inbox.
A concrete pass looks like this. Open the site on a phone. Find the main service in under a minute. Send a test inquiry with a real question. Check who received it, how long it sat there, and whether the reply sounded like a person who knew the business.
If that path fails, new colors and a new homepage animation will not save it. Fix the path first. Then redesign with a clear place for the inquiry to land and a clear owner on the other side.
An importer vetting a new supplier looks for three things before writing: what you ship, at what volume and with which certifications, and who will answer.
If your website makes them hunt for any of them, they email the supplier in the next tab.
Exactly. Let the model read the intent, and let fixed rules decide what happens next. Intent is also the most interesting part to go deeper on, because people don't always know how to say what they need, and sometimes what they ask for isn't quite what they're looking for. That's where the smart step earns its place.
Before you call it an AI agent: if you can write every step down in advance, you need an automation.
Agents earn their cost when the next step depends on what the customer just said. Most small-business tasks don't. Write yours down first.
A website rarely loses an inquiry. What happens after the form does.
An inbox nobody checks on Fridays. A form that lands with no one assigned to reply.
Before you redesign anything, follow one inquiry for 24 hours.
Three pricing models:
- per project: a full site
- per task: one bounded job in a site that already exists
- monthly capacity: a steady queue of requests
Whatever the model, ask: what counts as done, and what happens when the client asks for more?