# You Don't Need To Guess Right

DevFeed: [You Don't Need To Guess Right](<https://devfeed.tech/articles/you-don-t-need-to-guess-right-19845.md>)

Original publisher: [Read original article](<https://tech.gc.com/you-dont-need-to-guess-right/>)

Author: GameChanger

Published: 2017-05-06T21:07:20Z

Content type: article

Language: en

Sources: [GameChanger](<https://devfeed.tech/sources/gamechanger.md>)

Topics: [Back end](<https://devfeed.tech/topics/backend.md>), [API](<https://devfeed.tech/topics/api.md>), [Framework](<https://devfeed.tech/topics/framework.md>), [Koa](<https://devfeed.tech/topics/koa.md>), [TypeScript](<https://devfeed.tech/topics/typescript.md>), [Database](<https://devfeed.tech/topics/database.md>), [App](<https://devfeed.tech/topics/app.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [app](<https://devfeed.tech/tags/app.md>), [backend](<https://devfeed.tech/tags/backend.md>), [building](<https://devfeed.tech/tags/building.md>), [database](<https://devfeed.tech/tags/database.md>), [develop](<https://devfeed.tech/tags/develop.md>), [framework](<https://devfeed.tech/tags/framework.md>), [getting-started](<https://devfeed.tech/tags/getting-started.md>), [modular](<https://devfeed.tech/tags/modular.md>), [project](<https://devfeed.tech/tags/project.md>), [research](<https://devfeed.tech/tags/research.md>), [typescript](<https://devfeed.tech/tags/typescript.md>)

## AI overview

The article describes how two developers approached building a new backend API and app under significant uncertainty. They used modular design and short, well-researched decisions to reduce stress, ultimately choosing TypeScript, Koa, and Postgres for the initial stack.

## Source excerpt

I've been working on a new project recently, and when I say new, I mean brand new. This isn't just a lateral shift on the team to get my hands dirty in a new area of focus. Nor is it even adding a new product to our existing stack. This is building a brand new backend API for a brand new app. I'm really excited about being able to develop a new codebase, but the sheer number of unknowns and amount of work ahead is daunting. I wanted to share how my teammate Alex Etling and I embraced modular design to make our decision making process faster and less stressful. Let's start this story a few weeks ago, at the inception of the new team. The purpose of the app was clear, but I'm not sure I needed two hands to count the number of decisions that had been made. In that setting, Alex and I were given the mandate to figure out what the stack looks like and start building. We are both veterans at GameChanger, but neither of us had taken on something with this combination of future scale and current uncertainty. We've both architected solutions to a hard problems before, but when looking at a blank text editor and wondering what database should we use?, what language should we write this in?, and most terrifyingly what if we make the wrong choice?, it was hard to figure out where to start. Alex and I were getting started a few weeks ahead of the team that was going to be building the client app that will use this API. That means that we didn't have to spin something up immediately, but we knew that in a few weeks we had to have decisions made and a basic API ready for consumption. Everyone else who was working on the project at this point were focused on high level research, not implementation details. Alex and I had to start implementing crucial parts of the stack that could have long lasting consequences if we chose the wrong solution, without the clear definition of future product requirements and direction. It was a bit stressful. So we started. Alex and I split up and did