We've used the following criteria when deciding the technologies, architecture and tools to use.

• Code is a liability
  • We try to write as little code as possible. This means faster development, easier maintenance and quicker refactors and pivots.
• Speed of development / Developer ergonomics
  • We choose technologies and frameworks that are easy to understand and favor developer ergonomics: developers enjoy working on them and can develop features fast and reliably and iterate quickly. Development should be fun. It should also be easy to learn for new developers or devs coming from other technologies.
• Ease of attracting tech talent
  • We use technologies that are enough in vogue to be attractive for developers but make sure we don't fall into "developer vanity": we won't use an obscure language or framework or complex deploy systems and architectures just for the sake of it.
• Maturity of environment
  • We'll rather choose something older and battle-tested than something shiny and new. Fewer bugs, more libraries, better documentation. But there still needs to be a path ahead for the technology.
• Ease and simplicity of infrastructure
  • We want to reduce the complexity and cost of maintaining the infrastructure. Many apps nowadays can work at scale without the need for a single DevOps.
• Full-stack developers.
  • We are looking for cross-functional developers at this stage of the company. We need people that can build a feature from inception to deployment. Back and front.
• Nothing is final
  • We need to have in mind that features, interfaces, and requirements can and will change, so we have to make sure that we can easily absorb those changes.

The stack

• Language: Typescript.
  • We use Typescript (a Javascript typed superset) for a more predictable, faster, and less buggy development. Both for backend and frontend, this way all devs can work full-stack. Javascript has improved a lot in the last 10 years, there's a high adoption, and has a bright future (being the standard language of the web).
• Framework: Next.JS

  • Both for backend and frontend.

  • Next.js is a full-stack JS framework that leverages a set of tools and best practices and has a great development speed and is used by many of the top websites in the world.

    • Front End: React
    • Back End: Node.js (based on express)

    Companies used Next as a pure frontend framework but it's grown to allow any node.js backend in it. We've decided to use it since it ticks most of the boxes for us. If for any reason we are unhappy about it in the future, it's easy to extract all the code from the /api pages in Next and move it to another node.js framework. We'll have to design the file structure, modules, and dependencies with this in mind.

    Pros

    • Single codebase (back and front)
    • Fast to develop in
    • Easy for new devs (junior and senior) to grab
    • Comprehensive documentation and mature ecosystem (anything you want to do has been done before and is documented). There are many libraries that work with it.
    • Config that works out of the box:
      • Webpack config (polyfills, uglifiers, typescript, code splitting, eslint..)
      • Routing built-in (file-based routing)
      • Goodies (Image and font optimization, source maps, route prefetching, bundling optimization, CDN config...)
    • Easy SSR + SSG
      • We'll mostly be using SSR though
    • We can share data validation between back + front
    • Faster Time to First Byte

    Cons

    • Won't be using much of their most relevant features (SSG)
    • Slightly more complex frontend deploys (vs a single static file)
    • Stricter router (might find limitations with more dynamic routes)
• Infrastructure: Serverless

  • We want a scalable system that is simple to deploy and maintain, on which we don't have to worry if a system is down or has to scale. Serverless architectures have taken off the last few years and we can easily leverage their benefits with the tech stack we are choosing.

    • API + Server Side Rendering: serverless functions
    • Frontend: Static on CDN (we can use "intelligent" CDNs such as Netlify)

    Possible providers:

    • Vercel ← selected
    • Netlify
    • AWS lambda
• Database: PostgreSQL
  • Our data is going to be highly relational, and reading speed is not going to be a critical feature, so using a relational database makes the most sense. We'll use a hosted database for an easier and safer infrastructure.
  • Honorable mentions:
    • Vitess + Planetscale. We can further explore the possibilities of using these highly scalable SQL db system which also works with Prisma, our ORM of choice in case performance is an issue.
    • Supabase or Firebase. Expensive but convenient.
• ORM: Prisma
  • Best Typescript ORM we found.
• API specification / validation: OpenAPI
• Other tools and libraries:
  • CSS Framework: Tailwind
    • We'll use tailwind (a global library of utility classes based on your design system) instead of css-modules or css in js because it leverages the cascading nature of CSS and it's a more natural way to do so and easier to maintain and update.
  • Validation: ‣ (though we might not need it with OpenAPI)
  • Authorization: auth0
  • Form validation: react-hook-form
  • Error handling: ‣
  • Unit testing: Jest
  • Integration testing: Cypress
  • JSON Serialization: https://github.com/blitz-js/superjson
  • Background jobs: ? ← exploring possibilities: self-hosted (bull) or SQS
  • Component library: Storybook

Development processes and tools

• Version Control System: Git + Github
• Task management: Notion
• Continuous Integration: Github Actions