Six Months of Building in Public
A candid mid-year review of the SupportPages roadmap: the features that landed, the ones that missed, and what usage data changed about our priorities.
Building in public is mostly presented as a marketing tactic, which is why most of it reads like one. A screenshot of a graph, an emoji, a number that only goes up. The genre has a shape and the shape excludes the interesting half - the three weeks that produced nothing, the assumption that turned out backwards, the month where the honest update was that not much happened.
Six months of commits is a matter of record. Here is what they contain.
What actually shipped
January through June 2026, in order, with the month each landed:
| Month | What landed |
|---|---|
| January | Generated UI mockups inside articles; custom domains with automatic SSL |
| March | The VCS abstraction layer; Bitbucket Cloud support |
| April | Public repository support - no install step, no OAuth |
| May | The embeddable chat widget |
| June | The skill engine and the full migration onto it; recommendation pipeline rework; walkthrough title cards; the onboarding branding step |
The shape of that list is the interesting part. January and June were dense; April and May were nearly empty; March was almost entirely one piece of work that produced no visible feature at all.
The month almost nothing happened
May produced seven commits. Not seven features - seven commits, most of them small copy changes and the chat widget landing at the end of it.
I could construct a narrative about deliberate consolidation. What actually happened is more ordinary: April and May went into customer conversations, a conference, and a long stretch of deciding what the skill architecture should be before writing any of it. None of that produces commits, and by the middle of May the repository looked abandoned to anyone checking.
What came out of it was June - ninety-five commits, the skill engine, and the migration of every generation job onto it. That work was only fast because the two quiet months in front of it were spent working out what it should look like.
The reason this matters for anyone building in public is that a commit graph is a terrible proxy for progress and an excellent proxy for legibility. The quiet months were arguably the highest-value ones. They were also the two months I had least to say publicly, which creates a pressure I will come back to.
What we were wrong about
Two things, both wrong in the same direction: we assumed people wanted more control than they did.
The first was configuration. Early on every generation step had a setting, on the theory that engineers like knobs. Engineers do like knobs, but not before they trust the output - and a settings screen presented to someone who has not yet seen a single generated article is not empowering, it is a request to make decisions they have no basis for. The fix was making defaults good enough that most people never open the panel.
The second was onboarding. There used to be a second set of questions after the static five - generated per project by the analyzer, on the theory that it could work out what it could not infer and ask about that. It was cut entirely on 5 June, for reasons that are more embarrassing than "users disliked it" and are written up properly elsewhere. The short version is that the answers were reaching the generator with the questions stripped off, and nobody had read a payload in months.
The part that photographs badly
March was spent on the VCS abstraction layer, which produced no feature anyone could see and made Bitbucket support take a week instead of a quarter. June's skill engine is the same shape: pure infrastructure, no screenshot, and the thing that made video walkthroughs possible a few weeks later.
Writing a public update every week creates quiet pressure toward work that is legible in a paragraph. I have caught myself, more than once, sequencing tasks so there would be something to show on Friday. That is a real cost of building in public and it is not talked about, because admitting it undercuts the genre.
The mitigation I have landed on is to write about the invisible work anyway, at the risk of being boring, rather than reordering the roadmap around what demonstrates well.
The second half
Less new surface, more of the existing surface getting quietly better - which is a worse sentence for a launch post and a better plan.
If you have been following and something you expected has not appeared, I would rather hear it than not. That feedback has changed the order twice already.
About the Author
Simon Moxon has been building SaaS companies since 2009. He's scaled teams to 20+ people, hit £2m ARR, and learned most of the lessons the hard way. Now he's building SupportPages.io - help docs that write themselves when you ship code. He writes about what's changed in SaaS and what hasn't.