Deciding not to build: when no-code is the right call, and when it stops being one

In July 2025 I published emilybuilds.ai, the earlier version of this lab, on Notion and Super.so rather than coding it myself, because a coded site would have taken time I wanted for exploring AI tooling. I was in the middle of building Launchling, and what I needed was somewhere to write about what I was learning, quickly, without every post becoming a deployment. I asked ChatGPT for options, which included Framer, and picked Notion for the writing (I already used it) and Super.so to turn it into a website, with analytics included in its plan. I accepted $26 a month (about £19) as the price of not maintaining a front end, knowing I might replace it with a coded site one day; it was a trade-off, not an architecture.

What happened

I registered emilybuilds.ai on 6 July 2025 and the site was live on 9 July, after about two hours' work, the longest part of it fixing navigation and hidden pages. Three problems are worth recording, because none of them was about code:

• The domain. Connecting it meant editing the DNS settings on Namecheap, and the changes took long enough to spread that I panicked something was broken.
• Links. Links between pages worked best written by hand as absolute links with page addresses, which Notion kept trying to overwrite.
• Subpage links. Notion's links to subpages showed at the bottom of pages on the public site; deleting the subpages would have deleted the pages, so I hid the links with a Super setting.

None of them was hard on its own, but together they showed me that I was treating Notion as a content system and Super as an independent presentation layer, when in practice the structure of my Notion pages kept leaking through into the website; when something looked wrong, the first job was working out which of the two tools was responsible. No-code meant I didn't have to write the implementation, but it didn't excuse me from understanding the system; it moved the complexity to places I had less control over.

Browsing was the other limit, because the public site grouped posts by project, with a chronological list underneath, whereas this lab links builds, notes, tools and dates however I choose.

I also spent several hours failing to send email from my own domain before Namecheap's support team pointed me to part of the fix, which I wrote up at the time.

Was it the right call?

I think so, and I'd make the same decision with the same goal. I wanted to start publishing, and I was publishing within days rather than fussing with styling and layout; the writing I did on that site in 2025 mattered far more than its implementation. Deciding not to build is a skill I value more as building gets easier, not less.

Why I've rebuilt it now

When I launched it I wrote that "when I get tired of paying Super £16/month (ouch!), I'll code it up properly", though my invoices show the plan was $26 a month. What changed wasn't only the tools. In 2025 the question was how to get my work into the world without spending my time on a website; in 2026 the site is still where I show what I build and how, but building it is now one of the experiments too. The economics have shifted too: with a Claude agent in the Claude app I built emilysas.com, content system included, in about 42 hours elapsed from first commit to final launch change, so owning the code no longer competes with the writing in the way it would have then. This version runs on Astro with Keystatic, which keeps what I liked about Notion (writing without touching code) while separating the content from how it's presented, which was the thing I kept fighting in Super. Adding anything to the lab, whether a build, a note, a stack entry, a timeline event or a skill, is a form in Keystatic's editor, and the new item slots straight into the site's design with no layout work from me. I've written up how the new lab was built.

If you're weighing whether to build something yourself or buy a tool that gets you there sooner, I'd be glad to compare notes. Get in touch.