Deciding what to leave out

I’m building a consumer product on my own. It isn’t public yet, so this is about the method rather than the thing.

Almost all of the design effort has gone into subtraction. The interesting decisions were not which features to add — they were which capabilities to refuse, permanently, at the level of the data model rather than the interface.

The refusals

• No free-text field in anything a stranger sees. Visible content is composed by the system from fixed inputs, which means the feed cannot contain spam — not because anyone is moderating it, but because there is nowhere to put it.
• Rejection is silent. When someone isn’t chosen, nothing happens. No notification, no state they can observe. There is no rejected state to build, anywhere, and every future feature inherits that.
• Counts, never scores. Reliability signals only ever count upward. No percentages, no visible penalty, no number that can be driven down.
• No follower graph. Following is a notification subscription, not a social relationship, and there is no follower count anywhere.

Each of those was cheaper to decide once, structurally, than to defend repeatedly in review. The cost is real — you lose the ability to change your mind cheaply, because reintroducing any of them means building something new. For a product where the failure modes are social rather than technical, I think that trade is right.

The engineering underneath

Rails, one deployable application, laid out as a modular monolith: each bounded context owns its own data and declares which others it may depend on. CI fails the build if a module reaches into another module’s tables, so the architecture is enforced rather than agreed.

Feature work moves story by story from a written backlog with acceptance criteria attached. Nothing gets built from a conversation.

That last part matters more than it sounds, because most of it is built with agents — which is a separate piece.

In the index underconstraintsproductguardrailsexperiments