Seven Years Building: What I'd Tell My 2017 Self
Looking back on seven years of building web products, from Rome to the world, from first lines of code to 50K users. The advice I wish I had heard at the start.

It is the end of 2023, and I am looking back at seven years of building web products. In 2017, I'd been building iOS apps since 2008 and had launched Aviation Infinity on the App Store in 2014, but I was new to web development and had zero experience shipping web products to users. Today, I maintain multiple products across aviation, AI, and travel, and over 50,000 people have used something I built.
If I could go back and talk to that 2017 version of myself, here is what I'd say.
Ship Before You Are Ready
My 2017 self spent months building the web version of Aviation Infinity before showing it to a single user. I wanted the design to be perfect. I wanted the question bank to be complete. I wanted every edge case handled. By the time I launched, I'd invested hundreds of hours into features nobody had asked for.
The first users didn't care about the fancy quiz timer or the animated progress charts. They cared about two things: were the questions accurate, and did the interface work? Everything else was noise.
I'd tell my 2017 self: ship the question bank with a basic interface. Get feedback from real students within two weeks, not two months. You will learn more from five users in one week than from five months of solo development.
This lesson has only gotten more true over time. Every product I've launched since Aviation Infinity has launched earlier and scrappier. And every one has been better for it.
Your First Product Will Not Be Your Best Product
I was emotionally attached to my first product in a way that was unhealthy. Every criticism felt personal. Every bug felt like a moral failure. I couldn't separate the product from my identity.
Seven years later, I see my products as tools that serve users, not extensions of my ego. Aviation Infinity has had dozens of features that I built, measured, and killed because they didn't work. This doesn't bother me anymore. But in 2017, killing a feature felt like admitting failure.
I'd tell my 2017 self: your first product is practice. It might succeed, but its primary purpose is to teach you how to build products. Do not precious about it. Be willing to change everything based on what you learn.
Learn the Business, Not Just the Code
In 2017, I could build anything but I couldn't sell anything. I didn't understand pricing. I didn't understand positioning. I didn't understand distribution channels. I thought that building a great product was sufficient for success.
It is not. A great product that nobody knows about isn't a business. It is a hobby.
The skills that moved the needle for Aviation Infinity weren't technical. They were understanding which features flight schools needed to adopt the platform officially. Understanding how to price a subscription so that it felt like obvious value. Understanding which forums and communities student pilots frequented. Understanding the buying cycle of someone studying for pilot exams.
I'd tell my 2017 self: spend half your time building and half your time talking to users, understanding the market, and learning how to reach people. The code is the easy part.
Boring Technology is a Superpower
In 2017, I was drawn to new frameworks and shiny tools. I wanted to use the latest technology because it was exciting and because I thought it made me a better developer.
Seven years later, my entire portfolio runs on Next.js, TypeScript, MongoDB, and Tailwind CSS deployed on Vercel. Boring, proven technology that I know deeply. When something breaks at 2 AM, I don't need to Google the error. I've seen it before.
The most productive decision I made was standardizing on a single stack across all products. I use the same authentication patterns, the same database models, the same deployment pipeline, the same component library. When I start a new product, the infrastructure is done in a day because I've built it a dozen times.
I'd tell my 2017 self: pick a stack, learn it deeply, and resist the urge to switch. Depth beats breadth. Reliability beats novelty.
Revenue Beats Metrics
For a while, I tracked every vanity metric imaginable. Page views, daily active users, session duration, feature adoption rates. I had dashboards that made me feel like a real startup.
The metric that actually mattered was revenue. Specifically, monthly recurring revenue from paying users. Everything else was a proxy at best and a distraction at worst.
A product with 1,000 paying users is a business. A product with 100,000 free users is an unsolved monetization problem. I wasted time building features to increase engagement metrics when I should have been building features that users would pay for.
I'd tell my 2017 self: charge money from day one. Not because you need the revenue (though you do), but because paying users give you signal. They tell you what is valuable. Free users tell you what is interesting. These aren't the same thing.
Take Care of Yourself
This is the advice I most wish I'd followed. In 2018 and 2019, I worked constantly. Evenings, weekends, holidays. I told myself it was necessary, that I was building something important, that sacrifice now would pay off later.
What actually happened: I burned out. My code quality dropped. My product decisions got worse. I became reactive instead of strategic. The harder I worked, the less effective I became.
The version of me that's most productive is the one that sleeps eight hours, exercises regularly, takes weekends off, and has a life outside of work. This isn't lazy. This is sustainable. A burnt-out founder makes worse decisions than a rested one, and those bad decisions compound over months and years.
I'd tell my 2017 self: this is a marathon. You are going to be building products for decades. Pace yourself accordingly. The product will still be there on Monday.
The Market Matters More Than Your Skills
I've built products in markets that were too small, too competitive, and too early. In every case, the quality of the product was irrelevant because the market dynamics were wrong.
Aviation Infinity succeeded not just because I built a good product, but because the market was right. The incumbents were complacent. The users were underserved. The willingness to pay was high. The community was tight-knit enough for word of mouth to work. I got lucky with market selection, and then my execution mattered.
I'd tell my 2017 self: before you write a line of code, spend a week understanding the market. Who are the existing players? Why are customers unhappy with them? How big is the addressable market? How do customers find solutions? The answers to these questions matter more than your technical skills.
Compounding is Real
The most profound lesson of seven years is that compounding is real. Not just financial compounding, but compounding of skills, reputation, relationships, and code.
My code quality today is dramatically better than 2017 because every bug I fixed taught me something. My product instincts are sharper because every feature I shipped gave me data. My professional network is larger because every interaction built on previous ones. My productivity is higher because every product I built added to a library of reusable patterns and components.
The first year felt slow because I was building from nothing. Year seven feels fast because I am building on top of six years of accumulated assets. This compounding effect is the best argument for persistence. The returns on your effort increase over time, but only if you stay in the game long enough to accumulate them.
I'd tell my 2017 self: the first two years will feel unrewarding. The growth will be slow. The progress will be invisible. Keep building anyway. The compounding is happening even when you can't see it.
What I Would Not Change
Despite all the things I'd do differently, there are things I wouldn't change:
Starting solo. The skills I developed as a solo founder -- full-stack development, product thinking, business operations -- wouldn't have developed as quickly in a team environment.
Building in aviation. The niche seemed limiting at first, but it turned out to be the perfect market for a solo founder: small enough to avoid well-funded competition, passionate enough for organic growth, and serious enough that quality matters.
Growing up in Rome. The emphasis on craftsmanship, design, and quality that I absorbed growing up has been a consistent differentiator in everything I build.
Staying bootstrapped. Every product I've built is profitable or break-even. I've never been dependent on investors or at risk of running out of runway. This freedom is worth more than any amount of venture capital.
Looking Forward
Seven years is a long time and also no time at all. I am just getting started. The products I build in the next seven years will be built on top of everything I've learned so far, and with tools (like LLMs) that were unimaginable when I started.
To anyone at the beginning of their building journey in 2024: it gets better. The skills compound. The instincts sharpen. The tools improve. Just keep building.
Enjoyed this article?
I write about building products, AI, aviation, and the journey of entrepreneurship. Follow along for more.
Keep reading

Surfyx: What Building a Surf App Taught Me About Distribution
Surfyx is a surf tracking app and social network. Building it taught me that distribution, not features, determines whether a product succeeds in a niche market.

How I Use AI to Run a One-Person Product Studio
I maintain ~20 products solo. AI is not replacing my work, it is multiplying it. Here is how I use Claude and AI tooling to operate at impossible scale.

Building Software for Lawyers: UX Lessons from a Non-Lawyer
What I learned about designing legal software as someone who has never practiced law, and why outsider perspective might actually be an advantage.