Mareto is a wide product built by a small team. It makes listing websites, print brochures, social sets, client portals, brand systems, and the ledger that tracks what a listing costs — surfaces that at a larger company would each have their own team, designer, and roadmap.
People ask how that's possible. The honest answer is that it isn't, if you work the normal way. So these are the rules we actually operate by, including the ones that cost us something.
One owner per problem
Not one owner per feature — per problem. "Print output looks amateur" is a problem. "Add bleed settings" is a task someone invented while solving it.
The owner decides what gets built, ships it, and is the person who hears about it when it's wrong. No committee, no design review that everyone attends out of politeness. Two people looking at something carefully beats six people looking at it briefly, every time.
The cost of this is real: things ship that other people would have done differently. We've decided that's cheaper than the alternative, which is that nothing ships while everyone agrees.
Ship before it's polished, then finish it
The second half of that sentence is the part most teams drop.
Shipping early is only defensible if you go back. Our version: the first release is real but narrow — one path, working properly, with the rough edges named out loud rather than hidden. Then it gets used, and use tells you which rough edges were actually rough. Most weren't.
The failure mode we watch for isn't shipping something unfinished. It's shipping something unfinished and then moving on because the demo looked fine.
A standing veto on weight
Anyone can block anything that makes the product heavier, and the burden of proof sits with the person adding.
Heavier means: another setting, another concept the user has to hold, another place the same fact can live, another screen between someone and what they came for. Features are easy to justify one at a time — each is small, each has a requester. The weight is cumulative and nobody is accountable for it, which is exactly why it needs a veto rather than a discussion.
The corollary is that deleting is treated as work, not cleanup. We've removed whole surfaces — settings pages, duplicate ways of doing the same thing, an entire scheduling concept that never earned its place. Those were good weeks.
Build the system, not the instance
This is the rule that makes a wide product possible with few people, and it's the one that would sound like over-engineering if you saw it in isolation.
We don't build a brochure designer and a website designer and a social post designer. We build one asset model and one brand system, and the brochure, the site, and the posts are all outputs of it. A typography fix improves every surface at once. A new asset type is a fraction of the work it would be, because the hard parts already exist.
The tradeoff is that early progress looks slow, because you're building the thing that makes the things. There's a stretch where a team that hardcoded three templates is visibly ahead of you. You have to be willing to be behind for a while, which is more of a nerve problem than an engineering one.
Defaults over settings
Every settings toggle is an admission that we couldn't decide. Sometimes that's honest — people genuinely differ. Usually it's a way of avoiding an argument by shipping both options and making the user have it instead.
So the question is always: what's right for most people, most of the time? Pick that, make it the default, and only add the switch when someone real is genuinely blocked. The client portal is the clearest case of this — everything private by default, one deliberate exception, no configuration screen.
The part that doesn't scale, and that's fine
None of this is advice. A team of eighty can't operate on standing vetoes and single owners, and shouldn't try.
But the reason we write it down is that the rules are load-bearing for the product itself. A wide product built by a small team is only coherent if the surfaces share a foundation, and it only stays light if someone is empowered to say no. Those aren't process preferences. They're the reason the brochure and the website look like they came from the same place.
