Year One: 10 Lessons from My First Year Building Web Products

One year ago, I shipped my first web application. I'd been building iOS apps and aviation products since 2008, but web was new territory. Since then, I've built a restaurant platform, a hackathon discovery tool, and the beginnings of web-based aviation technology products. I've written thousands of lines of code, thrown away thousands more, and learned lessons that no online course, bootcamp, or tutorial ever taught me.

These aren't the lessons you find in "How to Build a Startup" blog posts. Those lessons are about product-market fit, growth hacking, and fundraising. These are the lessons you learn from actually building: the unglamorous, specific, practical things that determine whether you ship or stall.

Here are ten.

1. The First Version Should Embarrass You

Every product I built this year launched before it was ready. The restaurant platform had broken image uploads. The hackathon directory had stale listings. The first aviation tool crashed on certain browsers.

Each time, my instinct was to fix everything before anyone saw it. Each time, I overrode that instinct and shipped anyway. And each time, the feedback from real users was more valuable than the polish I'd have added.

The lesson isn't "ship garbage." The lesson is that your standard for "ready" is wrong when you're starting out. You overweight cosmetic issues and underweight functional feedback. A working product with ugly buttons teaches you more than a beautiful product that never ships.

I've started setting a personal rule: if I'm not slightly embarrassed by the first version, I waited too long.

2. Nobody Cares About Your Technology

When I built Comensalaqui, I spent time choosing between MongoDB and PostgreSQL, evaluating Express versus Koa, and debating client-side rendering versus server-side rendering.

Nobody who used the platform cared about any of those decisions. Users cared whether the restaurant listings were accurate. Whether the photos were appetizing. Whether the directions were correct. Whether the reservation actually worked.

The technology is the plumbing. Users care about the water, not the pipes. I still make careful technology choices because they affect development speed, maintenance burden, and reliability. But I've stopped confusing technology decisions with product decisions. They're related but not identical.

3. Finishing Is a Skill

Starting projects is easy. Ideas are exciting. The first few days of coding are energizing. Everything is new, every feature is satisfying to build, and the end product shimmers in your imagination.

Then you hit the middle. The excitement fades. The remaining work is tedious: edge cases, error handling, mobile responsiveness, deployment configuration, documentation. The fun features are done. The boring features remain.

Most projects die in the middle. Not because the idea was bad or the builder was incapable, but because finishing is harder than starting and nobody talks about it.

I've learned to push through the middle by making the remaining work visible. A list of every task between now and launch. Checking items off that list creates momentum that compensates for the faded excitement. The list replaces motivation with process.

4. Deployment Is Half the Battle

My first deployment took three days. Not because the application was complex, because I'd never deployed anything before. Server configuration, domain setup, SSL certificates, environment variables, process management, database connections: each one was a learning curve.

Now I use Zeit Now, and deployment is a non-event. But the lesson isn't "use Zeit." The lesson is that deployment infrastructure matters as much as application code, and ignoring it until the end creates unnecessary crisis.

I now set up deployment first, before writing a single line of application code. Push a project to Zeit Now, verify it works, then start building. This inverts the traditional order but eliminates the deployment crisis that kills projects at the finish line.

5. Users Don't Read

I built detailed onboarding flows with explanatory text. Users skipped them. I wrote clear error messages. Users ignored them. I created help pages with FAQ sections. Users never visited them.

Users don't read. They scan. They click. They experiment. They form assumptions based on visual patterns, not text instructions.

This reality changed how I design interfaces. Instead of explaining how a feature works, I design the feature so it doesn't need explanation. Instead of error messages that describe the problem, I prevent the problem from occurring. Instead of onboarding tutorials, I make the first action obvious.

The products I build now have almost no instructional text. The interface communicates through layout, color, and interaction patterns, not paragraphs.

6. Speed Beats Quality (at First)

In the first year of a product's life, speed matters more than quality. This sounds irresponsible. It's not.

Quality matters enormously for products with users who depend on them. Aviation safety tools need to be rock-solid. Financial calculations need to be precise. Medical information needs to be correct.

But for a product that's finding its market, that's testing whether anyone cares, speed of iteration beats quality of execution. A quick prototype that proves the concept is more valuable than a polished product that tests the wrong concept.

I've learned to distinguish between "this needs to be right" (safety, legal, financial) and "this needs to be fast" (new features, market tests, experiments). The default for new products is speed. Quality follows once the direction is validated.

7. Your First Users Are Your Product Team

The first ten users of any product I've built have contributed more to the product direction than any amount of planning.

They find bugs I missed. They request features I hadn't considered. They use the product in ways I didn't anticipate. They tell me, through their behavior, not their words, which features matter and which don't.

I've stopped building product roadmaps in isolation. Instead, I ship the minimal version, find ten users, and let their behavior shape the next version. This isn't "building what users want" in the lazy sense. It's observing how real people interact with a real product and using that data to make better decisions.

8. Revenue Validates, Usage Doesn't

Comensalaqui had users. People browsed restaurant listings, saved favorites, and left reviews. By usage metrics, the product was working.

But nobody paid for anything. The reservation commission model generated near-zero revenue. Users were willing to use a free product. They weren't willing to pay for it.

This taught me that usage and revenue are different signals. Usage tells you the product works. Revenue tells you the product matters. A product that works but doesn't matter is a hobby, not a business.

I now think about monetization from day one, not because I'm greedy, but because willingness to pay is the strongest signal of product-market fit. If someone won't pay $10/month for your product, they're telling you something important about its value.

9. Maintenance Is the Real Cost

Building a product takes weeks or months. Maintaining it takes years. The ratio of building time to maintenance time is roughly 1:10, and nobody warns you about this when you're starting.

Every product I launched this year still needs attention. Bug fixes, dependency updates, content refreshes, server maintenance, user support. The cumulative maintenance burden of multiple products is significant, and it grows with each new product.

I've learned to factor maintenance cost into every product decision. "Should I build this feature?" isn't just about development time. It's about maintenance time over the lifetime of the feature. A complex feature that takes a week to build and requires ongoing attention is more expensive than a simple feature that takes a week to build and runs unattended.

This calculation is why I choose boring technology. Boring technology has fewer bugs, fewer breaking changes, and more community support. The maintenance cost of boring technology is lower, which means I can maintain more products simultaneously.

10. The Second Year Is When It Gets Real

Year one was about learning to build for the web. I went from "I don't know how web applications work" to "I can build and deploy a web application." After 9 years of building iOS apps, adding web to my toolkit is a significant capability jump, and I'm proud of it.

But year one was also safe. The products were experiments. The users were few. The stakes were low. Nobody depended on my software for anything important.

Year two will be different. I'm building products for aviation, an industry where reliability matters, where users are professionals, and where the tools need to be correct, not just functional. The stakes are higher. The standards are stricter. The satisfaction of serving a real need is greater.

Year one taught me to build. Year two will teach me to build well.

---

Looking back at these ten lessons, the common thread is this: building products is less about code and more about judgment. The code is the easy part, it's learnable, debuggable, fixable. The judgment (what to build, when to ship, how to prioritize, when to quit) is the hard part. And judgment only comes from experience.

One year of experience isn't much. But it's infinitely more than zero.