In my five years of experience building apps for others, I was thrown into the trenches from day one.

Most juniors get tickets; I was handed whole apps on day one. No seniors to ask, no PMs to chew features for me. It was me against the void.

At first, it felt like an overwhelming burden, something I didn’t believe I could overcome. But at the same time I was blessed with the gift of being able to fail.

And — oh boy — I’ve failed fast and I’ve failed hard.

These are the four things I would keep doing in order to minimize (even more) the already statistically unlikely success of a product:

Spend months building around a core feature you haven’t proven works

In my second year as a SE, I built an app that used participants’ phone location to place them on a track and map in a web dashboard.

Instead of focusing on getting the core feature working well enough to test in real conditions and with real users, I spent months building and polishing around app features and design, while having never once tested outdoors.

After months of work, we realized the app wasn’t viable.

The GPS drifted by hundreds to thousands of meters depending on the phone and signal, making it completely unreliable for what the product actually needed to achieve.

Don’t care who your users are and be a clever boy/girl

In my first job I needed to build an interface to use on big interactive urban touch screens.

I wanted so badly to be noticed that, instead of bothering about UI/UX fundamentals and conventions, I created a beautiful, aesthetically pleasant design.

It was as beautiful as it was unusable.

The project was delayed by three weeks because no one but me could navigate the complexity of the interface.

There is always a place for creativity and good aesthetics, but in the early stages of a product it is rarely a priority.

Don’t validate the idea ASAP

I’ll never forget the time I had to sign a three-year-long NDA with a several-hundred-thousand-dollar fine for breaking it.

I remember thinking: this has to be big!

What a surprise it was when, at my first meeting, I realized I had signed an NDA for an idea.

The issue with ideas is that they seem valuable, they are presented as unique, they sound good in your head, and it seems like they are something worth protecting and working for.

But the real world always has different plans for your ideas.

Even if the idea is not already a product, even if you make it through the execution, the world may not give a “F” about your product.

The sooner you verify this, the sooner you can pivot the approach or completely ditch your idea.

Start working before knowing what problem you are trying to solve

On my second job, I joined a pre-seed startup. The founder was academically brilliant but had no idea how to develop a product. I was technically skilled but had no idea how people secured funding.

Every meeting would bring dozens of new ideas for the app. After narrowing things down, I started working on the first version of the app.

I worked my ass off, spending sleepless nights building and figuring out a tech stack I didn’t know, in a pre-AI era.

After we presented the project to various funding sources, I started losing faith in both the project and the management. I then received a job offer and left.

Weeks went by, and at some point I came to the realization that I had been wrong the whole time.

What the project actually needed was just a demo, not a full app.

A demo I could have built in a week with a bit of React, a component library, and an S3 bucket.

We had been working on the wrong solution the entire time. Instead of building a full product, we needed a simple demo to show investors and secure initial funding.

This was a hard lesson to swallow. I felt so dumb for a while, realizing I hadn’t understood something so simple: we didn’t need a full-featured app, just a lightweight proof of concept.

Before AI, people thought coding was the barrier. Now they think that since coding isn’t a barrier anymore, they can build a successful product.

What’s left is the thing that was always the real work: knowing who it’s for, whether they want it, and what it actually needs to do.

Five years in the trenches, and finally starting to see the big picture.