One of our interviews is a technical design question that asks the candidate to design a web-based system for public libraries. It explicitly tests for how simple they can keep it, starting at "a single small town library" scale and then changing the requirements to "every library in the country". The top ever performance was someone who answered that by estimating that even at max theoretical scale, all you need a medium sized server and Postgres.
Working with Shopify is an example of something where a good mental model of how it works under the hood is often required. This type of mistake, not realising that the tag is added by an app after an order is created and won't be available when sending the confirmation email, is an easy one to make, both for a human or an LLM just reading the docs. This is where AI that just reads the available docs is going to struggle, and won't replace actual experience with the platform.
Would Stripe's Connect work for you? They have all the tools for setting up a platform that onboards merchants, takes payments on their behalf and pays them out. You can sign up and use the sandbox for free, and only pay when you process transactions.
This is how our team does it as well. We are 5 engineers at a startup, so inbound support tickets that need to be turned around fairly urgently are common. Having one person dedicated to on call and dealing with support saves everyone else from constant context switching and leaves them to focus on planned work.
I think type checking helps with that both directly and indirectly.
It helps directly by making it much easier to know what type or shape everything is. Without types, all you have are variable names and tracing the code back up the stack yourself. Sometimes good naming conventions are enough. More often than not, a variable called `product` can be one of 3 different types and you have no idea why unless you go up the call stack to figure it out.
I find it also helps indirectly by making clever code harder to write. The dynamic nature of JavaScript encourages a degree of cleverness and meta-programming that makes things harder to understand. While you can do the same in TypeScript, making the complier happy makes it much harder to do so, which encourages more straightforward code.
Of course, you can write clever type definitions that are impossible to follow. Sometimes you do want to do some meta-programming without fighting the compiler. But in my experience, the path of least resistance when writing TypeScript is fairly straightforward OOP that tends to lead to clearer code.
You say 30 mins isn't enough for deep dives. Can you change from 30 mins every week to 60 mins every two weeks to allow more time for in-depth discussions?
What makes Daspoll different from to the many other existing survey products? It's not clear from the website how it's better compared to e.g. Typeform.
Good advice. But instead of having an entitlements _system_ and API calls passing through multiple different services returning lists of features a customer is entitled to, you can follow basic OOP principles and write
Not everywhere is like that. Smart small companies will eschew this unnecessary complexity to get more done with less.
For example, we have deliberately stuck with a single Node.js/Next app in a single repo using Postgres running on Heroku. We are 5 engineers now and plan to keep it that way for the foreseeable future, even as the team grows.
There is some complexity we probably don't need – the JavaScript ecosystem is notorious for this – but what we use is all reasonably boring tech at this point, and it allows us to stay productive as a team, focusing on delivering value instead of just maintaining things or chasing trends.