Case study · Edison Technology Park
The first site we built end to end with AI
Edison Technology Park is a family run business park in Menlo Park. Four buildings of startups, biotech, robotics, and hardware companies. We originally discussed a WordPress build on a nine week schedule. We built it with Lovable instead, and the whole site existed as a working, clickable app three days after we started.
The client
A business park that runs like an incubator
Edison Technology Park leases lab and R&D space at 3515 Edison Way in Menlo Park. The tenants are the kind of companies that need a fume hood installed and a forklift on site, so the park runs its own tenant improvement crew, its own generator, EV chargers, and a solar array across four roofs that covers close to all of the tenants' electricity.
It is family run, and that is the part they most wanted the site to carry. Bob Newdoll shared a Dropbox folder of photos with us in March 2025 and we talked through it over the spring. We signed the authorization to proceed on July 15.
The plan
What we scoped in July
What we originally discussed was a WordPress site on the schedule we have run for years. Wireframes, then mockups, then a build, with the client reviewing static comps at each gate. Launch was penciled for September 20.
- discovery
- 1 week · assets and sitemap
- wireframes
- 2 weeks · low fidelity, client feedback
- mockups
- 2 weeks · full branding applied
- development
- 2 weeks · WordPress skeleton and templates
- content
- 1 week · final copy and assets
- QA and launch
- 1 week · testing, go live
Fourteen pages on the sitemap, including four service detail pages, a gallery, an available units module, and a "Meet Your Neighbors" page for the tenant roster. That is a lot of surface for a small budget, and on the plan above none of it would have been clickable until late August.
The pivot
Lovable instead of wireframes
We put the spec through ChatGPT first, then handed it to Lovable. The first commit lands on
July 21, 2025 and says Use tech stack vite_react_shadcn_ts. The second one says
Implement Edison Technology Park website. Two days later the About page and the
remaining pages are in. Thirteen commits in the first three days, all of them authored by
Lovable's bot.
None of that was a prototype. Lovable published it to a public URL, so there was a real site at a real address that anyone could click through before we had written a line of code by hand.
The loop
Four tools, one repo
The setup that made this workable was connecting Lovable to GitHub on day one. Here is how Ed described it on the project board:
I'm pulling the repo down and opening it up in Cursor as a Workspace. With this setup we can make fine grain code updates, push back up the repo, and that will sync with Lovable.
That is the whole trick. Generation and hand editing write to the same history, so you are never choosing between the speed of the generator and the control of an editor. Prompt when a whole page needs to exist. Open the file when a class name is wrong.
- ChatGPT Project spec and wireframing guidelines, written before anything got built.
- Lovable Generated the site from the spec and published it to a public URL.
- GitHub Lovable commits straight to the repo, so the whole build has a history.
- Cursor Pull the repo down for fine grain edits, push back, Lovable stays in sync.
The review
The client reviewed a working site
We sent the staged site over on August 21, five weeks after signing. On the original schedule that week was the middle of the mockup phase. Ed framed it as the wireframe deliverable, because that is the slot it filled:
This initial iteration of the staged site will serve as our wireframe, site architecture, design and layout exploration, and componentry options.
Bob wrote back the next morning: "Wow, for only being the wire frame, the site looks fantastic!" Two weeks later he sent 26 numbered items after going through it with the other partners, opening with "we all LOVE the website, and are so excited to get it launched."
The 26 items are the actual argument for building this way. A sample:
- My mom didn’t know what that bouncing button was and didn’t know that you could scroll down for more information.
- Watch Video Tour link doesn’t work on home page.
- Take price off website for available spaces, that’s typical.
- Take off 24/7 on what sets us apart area. We don’t want to give the idea that we are available 24/7.
- At home page on the Designed for success heading, we need to remove the photo that shows Orca Bio’s name.
A broken video link, a scroll affordance his mother could not read, a leasing convention about not publishing prices, a tenant's name showing in a photo they had no right to use in marketing, and a service claim that would have committed them to 24/7 coverage they do not offer. Static mockups surface none of that. You get it when someone can click.
Scope
The site grew during review and nobody flinched
Item 9 on that list asked for a solar page that was not in the sitemap we quoted, and came with the copy attached: 2,300 panels across four roofs, 394,000 watts of peak DC, enough surplus on a hot afternoon to power 50 homes in Menlo Park and Redwood City. Those are their numbers, and they are a good reason to have a page.
It shipped on September 23, about three weeks after they asked. "What Makes Us Different" went the other way and folded into the homepage, so the site landed at fourteen pages and a 404, with five service detail pages instead of four. On a fixed price WordPress build, adding a page during client review is a change order conversation. Here it was an afternoon.
The catch
What an AI scaffold leaves you to fix
Lovable handed us a client rendered single page app. That is fine for a demo and bad for a leasing site, because the raw build ships an empty HTML shell and waits for JavaScript. Google will usually work it out. Social previews and the crawlers behind commercial real estate listings often will not.
So we added a prerender step. tools/prerender.mjs builds the app, serves it
through Vite preview, and walks every route with Puppeteer to write a static
index.html into dist/<route>/. Cloudflare Pages runs
npm run build:prerender as the build command, with Puppeteer launched no-sandbox
so it works in CI. Per route titles and OG tags come from Helmet.
The cost of that is a maintenance rule someone has to remember. Add a route in
App.tsx and you also add it to the ROUTES array in the prerender
script and to sitemap.xml, or the page ships as an empty shell. It is written
down in the README and the CLAUDE.md for exactly that reason.
- scaffold
- Lovable (vite_react_shadcn_ts)
- front end
- React 18 + Vite + TypeScript
- styles
- Tailwind, Bebas Neue and Inter
- components
- shadcn/ui on Radix
- routing
- React Router, 15 routes
- meta
- react-helmet-async, per route
- prerender
- Puppeteer, static HTML per route
- forms
- Formspree
- hosting
- Cloudflare Pages
Where the time went
Three days of build, three months of content
The build took three days. Everything after it took three months, and almost none of that was engineering. It was photo curation out of a Dropbox folder that had grown to a dozen subfolders of raw camera files, cutting the gallery down to the eight categories Bob wanted, matching copy to the Google Doc the family had written, and waiting on the units that were actually available to lease.
That ratio is the honest headline of this project. Generation collapsed the part of the schedule we are good at estimating and left the part we are not: getting the client's own material out of their heads and into the site.
Our take
More site than the budget would have bought
The site went live in mid October 2025 on Cloudflare Pages, and tenant inquiries come in through the contact form. Be honest about the calendar though. We penciled September 20 and went live in mid October, so this was not a schedule win. The page count came in about where we scoped it too.
What changed is the finish. Every page got a real design instead of a template with the brand colors dropped in: a video hero, a filtered gallery, per-unit leasing pages with their own photography, five service detail pages, and a component system underneath all of it. At this budget, on the WordPress plan, that level of build does not close. Ed's read at the end of it was that they got a good deal more website for the money than we could have delivered any other way, and that is still our read.
The other thing we would do again is staging a real site as the wireframe. Clients are not good at reading comps and they are excellent at reacting to a site. Five weeks in, Bob was forwarding a working URL to his partners instead of a PDF.
Who did the work
The team on this account
- Ed Reckers
- Ran the account and the client relationship, wrote the spec, set up the ChatGPT and Lovable and Cursor loop, and made the call to stage a working site instead of wireframes. Address corrections, favicon, analytics, mobile revisions.
- Michael Garcia
- The largest share of the commits. Content integration across every page, the Tenant Community section, the solar service page, gallery and available-units work, per-page meta tags, the prerender fix that made it build on Cloudflare, and the contact form repair.
Services on this account
- AI-assisted build
- React & Vite development
- Prerendering & SEO
- Content integration
- Photo curation
- Cloudflare Pages
Curious what an AI build would get you?
We run these the way we ran this one: generate the first version fast, then work it by hand where it counts. If you're a San Francisco Bay Area company sizing up a site, get in touch.