A look into our technology decisions

When launching a startup, the pressure to make perfect technological choices can be overwhelming. We all worry about making the "perfect" choice, fearing it's a decision set in stone. Thankfully, most modern languages and frameworks are robust enough to handle your initial needs and scale alongside your user base. A startup's true focus should be on acquiring those first customers, not scaling challenges that may not exist yet.

A startup's focus should be on acquiring first customers, not scaling challenges that do not exist yet.

Nevertheless, it's natural to want to get it right from the outset, and so did we. At Afterword, we believe in a "simplicity first" approach. We avoid unnecessary complexity until it becomes a genuine requirement. Forgoing a microservices architecture initially exemplifies this philosophy. While microservices excel at handling scale, a fledgling startup simply doesn't have that problem. Starting with a monolith allows for a smoother development process, with the option to gradually spin out microservices as specific functionalities require independent scaling. Our current setup reflects this – we've incorporated microservices alongside our core monolith, but that wasn't how we began.

Here's a breakdown of our tech stack:

• Backend: FastAPI
• Frontend: Svelte
• Database: MongoDB

Why FastAPI?

Building an AI application necessitates strong support for AI libraries, which Python excels at. Python's simple, clean syntax and ease of use have made it a favorite in the academic world. Developer experience (DX) is crucial, and it will be a recurring theme throughout this article. A positive DX translates to a positive user experience (UX) as well. Happy developers are more productive, delivering higher quality code faster.

Within the Python ecosystem, Django stood out as the most popular choice, and for good reason. It comes with a wide range of built-in features to streamline development. Additionally, Django is the powerhouse behind incredibly large and well-known applications like Instagram, demonstrating its scalability to handle massive user bases (2 billion in Instagram's case).

While I initially opted for Django, I later discovered FastAPI. This framework offers a key advantage: native support for asynchronous programming. This allows FastAPI to handle multiple concurrent requests very efficiently, unlike Django's synchronous approach.

Furthermore, FastAPI boasts a simpler learning curve compared to "batteries-included" frameworks like Django, making it a more approachable option for newcomers. Ultimately, FastAPI offered a superior DX and improved performance, benefiting both developers and our customer base.

Why Svelte?

In my search for front-end frameworks, I initially landed on React, the most popular option. Developed by Facebook, React boasts widespread adoption among companies of all sizes. While React was a strong contender, I eventually came across Svelte, which ultimately became my preferred choice.

Svelte boasts significant performance improvements. Unlike React, which ships its entire framework and utilizes a virtual DOM for updates, Svelte compiles your code to JavaScript during the build process. This translates to a smaller application footprint in the browser – less memory usage, faster loading times, and a more eco-friendly solution.

Furthermore, Svelte prioritizes developer experience. You can write significantly less code compared to React, making it easier to learn and maintain.

For even greater functionality, we leverage SvelteKit, a meta-framework built upon Svelte. SvelteKit offers valuable features like server-side rendering (SSR) for enhanced SEO and file-based routing for a more intuitive development experience. It's considered the best practice for Svelte projects.

Why Mongo DB?

Strong contender for most database projects, PostgreSQL is a safe bet. Its popularity is well-deserved. In our case, we initially opted for PostgreSQL before migrating to MongoDB.

• Data Structure: Our data wasn't well-suited for a relational model. It was highly hierarchical, containing nested documents and arrays. Storing this data in PostgreSQL would have required splitting it across multiple tables, leading to complex queries and joins.
• Schema Flexibility: During Afterword's rapid development phase, we needed a schema that could adapt easily. PostgreSQL's structured schema would have been cumbersome, especially considering the large amount of unstructured data we were working with from web scraping and various file formats (supporting both URLs and files). Inflexible schema would have resulted in many empty columns in our tables.
• Horizontal Scalability: MongoDB's horizontal scaling capabilities through sharding proved advantageous. Adding smaller servers in different regions reduced latency compared to vertically scaling a single PostgreSQL instance, which can be more expensive.

In conclusion, choosing the right tech stack for your startup is about balancing performance, developer experience, and your specific product needs. At Afterword, we prioritized technologies that allowed us to move quickly, adapt easily, and build a robust AI application. Remember, there's no one-size-fits-all solution – the best tech stack is the one that empowers your team to build and iterate on your product efficiently.