Skip to content
Obsidian
Start a project
Back to blog
Engineering

The Engineering Practices Behind Our Fastest Deliveries

How we consistently ship production-quality software in weeks, not months. The tools, processes, and principles that make speed and quality coexist.

AT
Aiko Tanaka

Speed and quality are not opposites. In fact, the practices that produce the highest quality code are the same ones that produce the fastest delivery. The secret is removing friction, not cutting corners.

After shipping dozens of production applications in tight timelines, here are the engineering practices that consistently make the difference.

1. Start With the Data Model

Before writing UI code, before setting up routing, before touching CSS — model the data. A clear, well-typed data model is the foundation everything else builds on.

We spend the first day of engineering on schema design:

  • Define every entity and its relationships.
  • Type everything with TypeScript interfaces.
  • Validate at the boundaries with Zod or similar.
  • Write seed scripts so the team can work with realistic data from day one.

This investment pays for itself immediately. When the data model is clear, frontend and backend can work in parallel. Decisions about UI layout become obvious because you know exactly what data is available.

2. Use Boring Technology

The fastest way to ship is to use tools you already know. We resist the urge to try new frameworks on client projects. Our stack is deliberately boring:

  • Next.js or Astro for the frontend. Both are mature, well-documented, and fast.
  • TypeScript everywhere. No exceptions. The type safety prevents entire categories of bugs.
  • PostgreSQL for relational data. It’s reliable, performant, and has excellent tooling.
  • Tailwind CSS for styling. It eliminates naming debates and produces consistent output.

“The goal of technology selection is not to pick the best tool — it’s to pick the most productive tool for this team, this project, this timeline.”

We evaluate new tools during internal projects, not client ones. Client projects get proven technology with known failure modes.

3. Automate the Pipeline From Day One

CI/CD is not something you add before launch. It’s something you set up before writing your first component.

Our standard pipeline runs on every push:

  • Type checking with tsc --noEmit. Catches type errors before they reach review.
  • Linting with ESLint. Enforces code standards automatically.
  • Tests for critical paths. Not exhaustive, but enough to catch regressions.
  • Preview deployments for every pull request. Reviewers see running code, not diffs.
  • Performance budgets with Lighthouse CI. Bundle size regressions are caught in CI.

This pipeline takes about 30 minutes to set up. It saves hours of debugging and days of coordination over the life of a project.

4. Ship Vertically, Not Horizontally

Horizontal development means building all the UI first, then all the API, then wiring them together. It’s tempting because it feels productive — you can show progress quickly. But it hides integration issues until the end, when fixing them is expensive.

Vertical development means building one complete feature at a time, from database to UI. Each feature is fully functional and deployable when it’s “done.”

The benefits are significant:

  • Earlier feedback. Stakeholders can test real features, not mockups.
  • Reduced integration risk. Every feature proves the full stack works together.
  • Clearer progress. Instead of “the UI is 80% done,” you can say “5 of 8 features are complete and deployed.”

5. Code Review as Knowledge Transfer

Code review in a fast-moving project isn’t about gatekeeping — it’s about knowledge sharing. Every team member should understand every part of the codebase, not just the parts they wrote.

Our review process is lightweight:

  • Every PR needs one approval.
  • Reviews should happen within 4 hours. Blocking on review is the most expensive delay.
  • Comments are categorized: blocker (must fix), suggestion (consider), nit (optional).
  • Reviewers focus on architecture and logic, not formatting (that’s what linters are for).

The result is a team that can work on any part of the codebase, not individuals who own silos. When someone is sick or on vacation, the project doesn’t stop.

Speed comes from preparation, not from rushing. A solid data model, proven technology, automated pipelines, vertical delivery, and fast code review — these practices create a system where quality and speed reinforce each other. The fastest teams are the ones with the best foundations.

All posts