100 days of engineering craft: lessons, explained simply

We've shipped 100 articles on engineering craft over the past hundred days, and we've learned more than we expected. This series wasn't designed to be a survey of technologies—it was a way to document the patterns, decisions, and trade-offs we make every day building backend systems, frontend applications, and infrastructure at Expona. Today we're wrapping up with four hard lessons that cut across every project we've worked on.

Fundamentals compound

The most valuable insight from a hundred days of writing is this: the basics matter more than anything else. Data modeling, API design, and reliability practices don't become less important as systems grow. They become exponentially more important. We've seen teams burn weeks optimizing cache layers when the real problem was a denormalized schema. We've watched incidents cascade because retry logic wasn't thought through in the first place.

Data modeling is the foundation. Every system we've built at Expona starts with the question: what does this data actually represent, and how will it change? A well-designed schema makes queries fast, migrations safe, and business logic clear. A poorly designed one makes everything slower and harder.

Consider a ride-hailing system. Early versions model rides as a simple table:

CREATE TABLE rides (
  id UUID PRIMARY KEY,
  user_id UUID,
  driver_id UUID,
  status VARCHAR,
  created_at TIMESTAMP,
  updated_at TIMESTAMP
);

This works until you need to track state transitions for debugging. Add a ride_events table and suddenly you can replay what happened. Add a ride_snapshots table and you can answer historical questions without scanning millions of rows. The schema evolves because the data model becomes explicit.

APIs are similar. A well-designed API makes it obvious what the client should do. Parameters are named clearly, errors are predictable, versioning is forward-compatible. We've spent more time on this than any other single topic because APIs are where systems touch. Get them wrong and every downstream team pays the price.

Reliability is the third pillar. Timeouts, retries, circuit breakers, and observability aren't fancy features—they're requirements. We've built systems that looked fast in testing and failed under load because we skipped these. The cost of adding them after launch is always higher than building them in.

Here's what matters: these three things—data modeling, API design, and reliability—appear in every project we work on. They're not trendy. They're foundational. And they compound. A team that gets all three right ships faster than a team that optimizes one and neglects the others.

People skills scale impact

Technical skill gets you hired. People skills get you promoted and multiply your impact. We learned this early and kept learning it throughout this series.

Code review is the most underrated practice in engineering. When done well, it's not a bottleneck—it's a multiplier. We've seen senior engineers on small teams review PRs thoughtfully, and that team ships better code faster than teams twice their size that skip reviews. Why? Because the junior engineers absorb patterns. They see what good looks like. They ask better questions. The investment compounds.

Mentoring works the same way. One of us spent an hour with a junior engineer debugging a race condition in a WebSocket handler. That engineer then mentored someone else on the team. Six months later, the team had built a culture where concurrency issues got caught in review. The original hour of mentoring prevented dozens of production incidents.

Communication deserves its own section. We've worked with teams that built amazing things and shipped them to dead silence because they didn't explain why it mattered. We've worked with teams that shipped less impressive things and became heroes because they told a clear story. Documentation, pull request descriptions, architecture decisions written down—these all sound like overhead. They're not. They're how teams think clearly.

This series itself is an example. We've written about data modeling, WebSockets, Kafka, state machines, performance tuning, and a hundred other topics. The act of writing forced us to think clearly. Readers then asked questions we hadn't considered. Those questions made our systems better. The feedback loop is real.

Simplicity is a decision

The best systems we've built were almost always the simplest ones that solved the problem. Not the simplest possible systems. The simplest ones that actually worked.

This requires discipline. There's constant pressure to add features, build frameworks, optimize prematurely. We've fallen into all these traps. A CRM team built a flexible rule engine to handle business logic. It was beautiful and complex and shipped six months late. They should have shipped a simple state machine and iterated.

Simplicity means different things at different layers. For data models, it means normalizing enough but not too much. For APIs, it means picking one pattern and sticking with it instead of mixing REST, GraphQL, and gRPC. For infrastructure, it means deploying to containers and managed databases instead of building custom orchestration.

We've seen teams pick technologies because they're powerful, not because they're necessary. A trading system doesn't need Kafka if messages are already persisted in PostgreSQL with a queue table. An e-commerce site doesn't need Redis if queries are already fast. Adding complexity to solve problems you don't have yet is expensive—it costs engineering time, operational overhead, and headcount.

The simplest systems tend to be the most reliable too. There are fewer places for bugs to hide. Fewer dependencies. Fewer failure modes. Fewer things to monitor. We've built high-throughput systems using boring technology and patterns. They're slower to conceptualize but faster to ship and operate.

Keep learning in public

Every article in this series is published on expona.dev because learning in public forces you to be honest. You can't fake understanding when readers will see the holes. You can't hand-wave trade-offs when you have to write them down. The public nature of the series made it better.

We wrote about failures too. Systems that didn't scale the way we expected. Migrations that took longer than planned. Infrastructure decisions that turned out to be wrong. Publishing these felt risky and then it became clear: that's exactly what people need to read. Senior engineers don't need to hear about perfect systems. They need to hear about real ones.

This is where we ask for your help. What should we write about next? What problems are you solving that aren't covered in the series? What decisions are you wrestling with? We've built systems in .NET, NestJS, Next.js, React, React Native, and Flutter. We've worked with Kafka, WebSockets, PostgreSQL, Redis, Docker, and AWS. We've scaled CRM systems, trading platforms, ride-hailing apps, and SaaS products.

The next hundred days of engineering craft articles will be shaped by what you need. You know how to reach us through expona.dev. Tell us what's hard. Tell us what worked. Tell us what you tried that didn't. The best way to stay sharp is to keep learning in public, and we do that better when we're learning from you.

Common mistakes

• Assuming fundamentals don't matter at your scale. They matter more as you scale. A schema that works for 100K users will break at 1M. An API that feels fine with one client breaks with ten. Start right.
• Treating code review as a gate instead of a tool. If reviews feel slow, they're not being done right. They should feel like collaboration. If they're taking hours, the PR is too big or the team doesn't share context.
• Confusing simplicity with naivety. Simple doesn't mean ignoring production requirements. It means building the minimum that actually works in production, not the minimum that works in a demo.
• Learning alone. Writing it down forces you to think clearly. Teaching it forces you to understand completely. Do both.

Key takeaways

• Data modeling, API design, and reliability are not options—they're required. Invest in them from day one.
• Your impact multiplies through other people. Reviews, mentoring, and clear communication compound faster than individual contribution.
• Simplicity is choosing the minimum system that works in production, not the minimum system that works in theory.
• Learning and teaching in public makes you better. It also makes the whole team better. Keep writing. Keep sharing.