A site, a domain and a Google profile in ninety seconds

by Smeron, Product studio

3 August 2026 · 4 min read

A Neweb-generated business site, produced from a four-question intake form.
Neweb: one intake form provisions the site, claims the domain and populates the business profiles.

A local business owner will not finish a website between jobs. Neweb removes the building entirely: four questions, then a live site, a claimed domain and a synced Google profile.

Site builders lose people at the blank canvas. That is not a usability complaint, it is the entire funnel: for a self-serve product sold to people who are busy doing something else, onboarding drop-off is the business. Neweb sells an online presence as a subscription, so the product had to replace the build with an outcome.

Four questions: business, location, industry, name. No design decisions, no template gallery, no colour picker. Then, in about ninety seconds, a production site, a claimed domain, and a Google Business Profile populated from the same answers.

Ninety seconds is a promise about questions, not speed

The number matters less than what it implies. Nothing in the middle of that pipeline is allowed to ask the customer anything. Every decision a builder would normally delegate (layout, section order, the copy in the hero, which photos go where) has to be resolved from four inputs and an industry, which means the interesting work is in the defaults rather than in the generation.

Ninety seconds is not a speed claim. It is a promise that nothing in the middle stops to ask the customer a question.

Five external systems, one of which is going to fail

Behind the form there is a chain: a domain registrar, DNS, a WordPress build driven as an engine rather than used as a product, Google Business Profile, and Bing Places. All five are someone else's API on someone else's day. The failure that matters is not the one that happens before the form submits. It is the one that happens after the customer has been told it is working.

  • Every step is idempotent, because the only safe way to recover from a half-finished provision is to run it again.
  • The job is resumable and knows which steps have already succeeded, so a Google API outage does not cost the customer their domain.
  • Business details are held in one place and pushed outward, so a corrected phone number does not stay wrong on Google for a year after it was fixed on the site.

That last point sounds like data modelling and is actually the retention argument. A site nobody finds gets cancelled; a profile with last year's opening hours is worse than no profile. The sync is why the product is worth paying for monthly rather than once.

Upkeep is the product, not the launch

Most SEO work on a small business site is a launch checklist that nobody opens again. Here it runs as background passes: schema markup, meta tags and sitemaps revisited weekly, with performance monitored on every deployed site. The budget we held ourselves to was an LCP under a second, which is what both local search and an impatient person on a phone reward.

What this pattern is good for

Automated provisioning turns a studio's client sites from a production queue into a line they can resell, which is why agencies were an audience nobody planned for. More generally: if your onboarding asks a customer to make decisions they do not have opinions about, the fix is rarely a better form. It is removing the decisions, then making the pipeline behind them survive a bad afternoon.

Questions this comes up with

The things people ask after reading it, answered in the words they ask them.

Where this came from

Read nextTurning plain English into Terraform you would actually mergeA prompt that returns cloud infrastructure demos beautifully. What decides whether anyone is still using it a month later is what the generated code looks like when something has to change.

Want this applied to your own stack?

Fifteen minutes with the people who built the thing in this post. No deck.