Six things I believe about making software

Okay. So this is going to be one of those essays where I try to articulate something that mostly lives as intuition. The principles that guide how I build software. I want to write them down not because I think they're universally correct or that everyone should adopt them, but because writing things down is how I figure out if I actually believe them or if I'm just telling myself a story. Think of this as a snapshot — a marker of this time that I can revisit later and see if I still agree with myself.

Some context. I run a small software studio called Serendipity Labs from Kerala, India. It's me and a small team of interns. We've shipped about a dozen products across iOS, web, and desktop. Some of them do well, some of them don't. The following six principles are what guide the decisions we make — what to build, how to build it, when to stop.

1. Good software is good art.

This is the one that sounds pretentious so let me try to explain what I actually mean by it. I don't mean software should be decorative or that we should prioritize aesthetics over function. What I mean is that the best software I've ever used feels like it has a point of view. It makes choices. It says no to things. When you use a well-made tool, you can feel the presence of a mind behind it — someone who thought carefully about what to include and what to leave out.

Most software doesn't feel this way. Most software feels like it was assembled by a process rather than crafted by a person. Every possible use case gets a toggle. Every edge case gets a modal. The result is something that technically does everything but spiritually does nothing. It has no opinion.

I think there's something valuable in software that feels like one person (or a small group of people with shared taste) made it. That coherence — that sense of a singular vision running through every screen — is something I try to maintain. Whether I succeed is a different question, but the attempt matters to me.

2. Ship fast, iterate faster.

I used to be a perfectionist. I'd spend months polishing something before showing it to anyone. Then I'd launch and discover that the thing I'd spent the most time on was the thing nobody cared about. The feature I'd almost cut was the one people loved. This happened enough times that I had to accept the obvious lesson: quality is impossible to achieve in isolation. You need contact with reality.

Now I try to ship the smallest possible version of an idea as quickly as I can. Not because I don't care about quality — I care deeply — but because the feedback loop between "I think this is good" and "actual humans confirm this is good" needs to be as short as possible. The longer that loop, the more time you spend building in the wrong direction.

The first version of one of our apps was embarrassingly simple. Barely two screens. But it shipped in two weeks, and within a month I knew exactly what to build next because users showed me through the specific, concrete ways they used (and misused) what I'd given them. No survey could have surfaced those insights.

3. Simplicity is the ultimate sophistication.

Every feature you add to a product has a cost. Not just the cost of building it — that's the easy part. The real costs are harder to see: the cognitive load on every future user who has to understand what this button does, the maintenance burden on future-you who has to keep it working across OS updates, the interaction effects with every other feature that now has one more thing to be compatible with.

I think of features like furniture in a room. A few well-chosen pieces make a room feel intentional and livable. But keep adding furniture and eventually you can't walk through it. Most software has too much furniture. The people who built it kept saying yes when they should have been saying no.

My rule, which I don't always follow but try to: if I can't explain what a feature does in one sentence, it's too complex. If removing it wouldn't make anyone's actual workflow worse, it shouldn't exist.

4. Independence over infinite scale.

I chose to build a small indie studio rather than pursue the more conventional path of raising capital and scaling a team. This wasn't a moral judgment on other approaches — plenty of great software comes from well-funded companies with large teams. It was more of a personal realization about what I actually want from my work.

What I want is autonomy. I want to decide what to build. I want to be able to say "this product is done" without external pressure to keep growing it. I want the freedom to experiment, to ship something weird, to pursue an idea that might not have obvious market potential but feels interesting.

The trade-off is real and I'm not going to pretend otherwise. There are entire categories of products I can't build because they require resources I don't have. But within the space of things a small team can build, I think we can compete on taste, on speed, on the willingness to make opinionated choices that a larger organization would committee into blandness.

5. Profit is freedom.

There's this thing in my head where I need the work to be self-sustaining. Not because I'm obsessed with revenue numbers or growth metrics, but because financial sustainability is what lets me keep doing this without answering to anyone. It's what keeps the lights on and the autonomy intact.

I think of it simply: revenue is a tool for sustainable building. It means I can keep shipping next month. It means the studio stays independent. It means I don't have to take meetings with people who want to "align on strategy." Revenue isn't a vanity metric for me — it's what keeps the work going without compromising on how we do it.

6. Small teams, big impact.

We're a tiny team. Me and a few interns. This is sometimes lonely and often exhausting. But it has one enormous advantage: I get to design the processes and systems that work for us. I can try something, see if it fits, tweak it, throw it out entirely if it doesn't serve us. There's no inherited bureaucracy, no "this is how we've always done it." The way we work is itself a thing I get to build and iterate on.

I think people dramatically underestimate what a small motivated group can accomplish with modern tools. The gap between what a tiny team can build today versus ten years ago is enormous. Better frameworks, better infrastructure, better AI tooling — all of it compounds into a world where you don't need fifty people to ship a product that feels polished and complete.

This doesn't mean large teams are bad. It means the minimum viable team size has dropped significantly for a surprisingly large class of products. And when your team is small, you can optimize for things that larger teams structurally cannot: speed, coherence, and the willingness to make unpopular decisions quickly.

These six things aren't rules. They're more like a compass — something I check against when I'm not sure which direction to go. I don't always follow them perfectly. Sometimes I ship too slowly because I'm being precious about details that don't matter. Sometimes I add a feature I shouldn't because someone asked nicely. Sometimes I undercharge because I'm afraid of losing users.

But having them written down means I can notice when I'm drifting and correct course. And maybe in a year I'll read this back and disagree with half of it. That would be fine. That would mean I learned something.

If you're thinking about building software independently — whether solo or with a small team — I won't tell you it's easy or that you should definitely do it. I'll say this: figure out what you actually want your days to look like. Not what sounds impressive, not what would make a good LinkedIn post, not what your relatives would understand at a family gathering. What do you actually want? If the answer involves making things with your hands and putting them directly in front of people who use them — then maybe this path is worth exploring.