A Small Feature Isn't Always a Small Change
One thing building my own website has changed for me is how I interpret the phrase “we can add that later.”
Sometimes that's absolutely true.
But “later” becomes more interesting once a website has an existing structure.
When I added public product documentation to Cordinant, the visible idea was simple: products should have documentation that visitors can read.
But the documentation needed somewhere to live in the database. I needed a way to manage it in the admin area. It had to connect to the correct product. Public URLs had to make sense. Navigation, internal links and the sitemap also became part of the discussion.
None of those things is especially dramatic on its own.
Together, though, they make “add documentation” quite different from simply adding another block of text to a page.
I've started thinking about future features less as “Can this be added?” and more as “What will this need to connect to?”
For those building products over time: which supposedly small addition ended up touching much more of your system than you expected?
For me it was a dropdown. I wanted the user to pick a country instead of a currency on the pricing screen and it sounded like an afternoon. It ended as nine separate tasks: pricing, checkout, legal docs and the settings page. The dropdown itself was the smallest part.
The gap is between the feature's surface area and its structural footprint. 'Add documentation' sounds like a content problem. But it's really a data model problem, an admin problem, a URL problem, and a navigation problem all at once.
The useful frame I've found: estimate by asking 'what has to know about this?' If the answer is more than two systems, it's probably not small. A new text block on a page touches the CMS and maybe CSS. A new entity with relationships touches the database schema, the admin UI, the public routing, SEO metadata, and sitemap. Same visible complexity, very different technical scope.
The 'we can add that later' cases that work are usually presentation-only changes. The ones that don't are usually anything that requires a new noun in the data model.
That's a really useful way to frame it — “what has to know about this?”
The distinction between a presentation change and introducing a new “noun” into the system also makes a lot of sense. That’s pretty much what happened with documentation on my site. The pages themselves weren’t particularly complicated. It was the moment documentation became its own type of content, with relationships to products, its own URLs and a place in the admin area, that the scope grew.
I think that’s also why these changes can be difficult to judge from the finished UI. Two additions can look equally small to a visitor while being completely different underneath.
"We can add that later" hides the real cost: the feature has to fit a structure that already exists. Documentation pages sound small until they need a URL scheme, a nav slot, and a way to stay current.
Same trap on a small directory product we run. Adding "list your server" looked like one form. It pulled in moderation, a public card, and a ranking rule so paid placement could not rewrite the score. The form was the easy part.
When you added public docs, what broke first — navigation, content ownership, or search?
That’s a good example — the form is what the user sees, but moderation and ranking rules are where the feature really starts growing.
In my case, I wouldn’t say one particular thing “broke” first. It was more that adding public documentation exposed how many decisions were connected. I needed to think about how docs relate to products, how I manage them in the admin area, their URLs, and how visitors get from a product page to the relevant documentation.
So the unexpected part wasn’t fixing one broken piece. It was realising that “add documentation” had quietly become a small system of its own.