I need some advice. Small team, big problem. Limited budget. Looking to keep costs down, team happy, Product sustainable and viable.

These are all legit questions that can be answered. However I would really recommend either investing in the right person for tech leadership and/or involve the developers you bring onboard in these conversations.

For engineers in a starting company, being involved with these decisions can greatly increase the level of ownership, understanding and responsibility from individuals. Increased ownership and understanding in turn will help building higher quality and maintainable code.

You would want this because the opposite effect is really negative. Developers will need to start working with technology that they might not agree with, lack experience of or won't understand why the decision for ie AWS/flutter has been made. That directly influences happiness, turnover and the quality of code.

Having great technical leadership can also help, because they can explain decisions and control the quality. Just slapping documentation as a requirement might not help as much.

For longevity of code; Also make sure to properly track changes being made in Github (this is super standard), because in Pull Requests and Issues you can document the considerations and concerns of certain code parts (ADRs as mentioned by @fbonneau), rather that just how they work.

Overall it's super exciting to start a new project, but they way you start it and how final decisions are made are super important for the early development team. After that a lot more technical decisions will be made, for which you want a good process too.

Good luck!

I wouldn't optimise server costs before you're confident product/market fit is incoming. I'd recommend to first build a cheap and dirty MVP using throwaway tech, but it sounds like you may be past that stage.

AWS can be pretty cheap (AWS lambda for example), but it has to be a good fit for what you're building. If your developers feel constrained building serverless on lambda, then that decision would be expensive in terms of development time and headache, and not be worth it. Developer happiness usually trumps server costs.

To me, pool tables etc aren't important but good salary, nice people and a product I believe in are.

PS: Where in Africa? Hi from Cape Town 😃

I'll just add my two cents on a small part of your question:

"Do developers and other tech folks really care about pool tables and other cool contraptions I see in most tech company offices?"

In my opinion, NO! In fact as a very experienced developer, if any company running ads looking to hire me feel a need to highlight the fact that they have pool tables, video games, beer on Fridays etc, I don't even consider applying - there are lots of reasons I might or might not take any given job, but a pool table (or similar items) will never be one of them - and in fact, the simple fact that a company felt in important enough to advertise as a 'perk', tells me all I need to know about what it will be like working there.

Nothing wrong with having said 'perks' I guess, but thinking that is a going to be a deciding factor in anyone's decision about making a multi-year commitment to an employer is pretty lame.

So many random questions not well organised, let me try to address a few

• AWS brings many advantages, but best cost is not one of them. If you want better pricing there you have to remove flexibility and commit to high until. Nodes for a long period. (They might be best value for other reasons like time saving for many things).
• Bypassing Apple payments via payment on website as far as I know is not allowed and would not be approved, you have to pay the 30% tax, on Android might be allowed (I'm not an app guy) (there might have been a few hand selected exceptions made with huge struggles..)
• There are things more important than office like benefits that change between locations but commonly include health benefits, learning funds, tooling allocations and other smaller things. It also depends highly on who you complete with for talent, supply and demand. Attracting and keeping talent is a big topic. Lab days are another "benefit" some provide and might be highly appreciated and can be useful...
• I'd you want more stable easy to onboard code, put more time into docs, including system and code architecture and design and that they happen before coding. And allocate upkeep/refactor/taking care of code time