How a Small Team Builds Products (Without Losing Our Minds)
No corporate buzzwords were harmed in the writing of this post.
We're fourteen people. That's small enough that everyone knows what everyone else is working on, but big enough that you can't just wing it without any process.
This size is weird. Too big for "let's all hop on a call and figure it out," too small for departments and managers and formal hierarchies. We've had to figure out how to actually build products at this scale, and honestly, we're still figuring it out.
What We're Actually Building
Right now we're working on two main things:
- Arheev - Our HR platform for growing companies. It's the product we're building for ourselves (and others who need it).
- Client projects - We do custom development work for startups and companies that need technical expertise they don't have in-house.
Juggling both is chaos sometimes. We'll be deep in Arheev feature work, then a client project hits a critical bug and half the team pivots. Or we'll plan a client sprint, then realize Arheev needs something urgent for a demo next week.
At fourteen people, there's no "separate teams" solution. Everyone touches everything.
How We Actually Make Decisions
In a big company, there are process documents and approval chains. At our size, that's overkill.
Instead, we have one rule: if you think something should be done, prototype it.
Not "schedule a meeting to discuss it." Not "write a proposal for review." Just build a rough version and show it to the team.
This sounds chaotic. Sometimes it is. But it also means we move fast and kill bad ideas quickly. Way better than spending two weeks debating something in meetings, then building it and realizing it doesn't work.
Marko (our Head of Engineering) came from a place where every change required three levels of approval. He says the first time someone at Norveon told him "just ship it and see what happens," he thought it was a test.
It wasn't. We genuinely trust each other to make judgment calls.
The Friday Failure Report
Every Friday, we have a standing meeting where people share what didn't work that week.
Not successes. Failures.
The Azure deployment that broke production. The feature we built that users hate. The refactor that made performance worse instead of better. The client meeting that went sideways.
Early on, people were reluctant to share failures. Now it's the most useful meeting we have. You learn way more from "here's what I broke and how I fixed it" than from "here's what went well."
When the Junior Developer Was Right
Building Arheev, we spent weeks designing the dashboard layout. Multiple iterations, lots of discussion about information hierarchy and user workflows.
Then someone newer to the team (who'd been quiet in most meetings) pushed a prototype to staging that threw out our entire navigation approach. Just... completely different.
The first reaction was "this breaks all our design patterns." The second reaction, after actually using it, was "wait, this actually works better."
We ended up shipping their version. Took about two more weeks to refine it, but the core idea - which came from someone who hadn't been part of all our previous discussions and assumptions - solved the problem better than our "expert" approach.
The lesson: sometimes being new means you haven't learned all the wrong patterns yet.
The Things That Don't Scale (But We Do Anyway)
At fourteen people, we can still do things that bigger companies can't:
Everyone reviews everyone's code. Not just senior developers reviewing juniors. Everyone sees everyone's work. This means code reviews sometimes take longer, but it also means knowledge spreads fast.
We ship directly to production. No separate deployment team, no change approval board. If you built it and it passed tests, you can deploy it. This terrifies people from bigger companies. We're fine with it.
Everyone talks to clients. There's no "account management team" shielding developers from users. If you built the feature, you might be the one demoing it or debugging it with the customer. This is inefficient. It's also how you learn what actually matters.
What Happens When This Doesn't Work
Not everything is perfect. Some things at our size just... suck.
Knowledge silos still form. Even with code reviews and shared projects, one person ends up being "the one who knows how the deployment works" or "the one who understands the payment flow." When they're on vacation, things slow down.
Politics still exist. Smaller team doesn't mean no disagreements or hurt feelings. We just have fewer places to hide from them.
Growth is weird. We're too small for specialized roles but too big for everyone to do everything. Do we hire another generalist developer or find a specialized designer? Wrong choice and we're unbalanced for months.
We don't have solutions to all of these. We're just aware they exist and trying not to make them worse.
Why This Matters for Products
The way we work directly affects what we build.
Arheev (our HR platform) has this feature where you can customize basically everything. Workflows, permissions, data fields, reporting - all configurable. Not because we planned to build "the most flexible HR system" but because that's how we work internally.
We hate being forced into rigid processes, so we built a tool that doesn't force users into rigid processes.
Could a bigger, more structured team have built something similar? Maybe. But it would have taken more meetings, more planning, more layers of approval. By the time they shipped, the market would have moved.
At fourteen people, we can move fast because there's nowhere to hide bad ideas. They get caught in code review, or in Friday's failure meeting, or when someone tries to actually use the feature and realizes it's terrible.
Where We Are
We haven't figured out the perfect way to build products. Nobody has. We're just sharing what works for us at this size, at this stage.
Some of this will break as we grow. Some of it already doesn't work as well as it did when we were smaller. We'll adapt, or we won't, and we'll write about that too.
Ask us again in a year and the answer might be different.
