We pick tools a small team can still maintain a year from now. That usually rules out whatever launched last month, and it usually favors tools with good documentation, a large community and hosting that doesn't need a full-time engineer.
These are our defaults and the reasons behind them. Every project starts here and changes when the product asks for it.
How we choose
Four questions settle most decisions. Can the client hire someone who knows this tool? Is the documentation good enough to solve problems without us? What does it cost to host when traffic grows? And how hard would it be to move away from it later?
Marketing sites: Astro
For marketing sites we use Astro. It ships pages as static HTML and loads JavaScript only for the parts that need it, which keeps pages fast without extra work. This site is built with Astro, and so are most landing pages we ship. When a site needs frequent content updates, we connect a headless CMS so the team can edit without touching code.
Mobile apps: React Native
For mobile apps we use React Native. One codebase reaches iOS and Android, so features ship to both platforms together and the team doesn't maintain two apps. It also shares TypeScript with the web, which makes it easier to reuse logic and hire.
Data and sign-in: Supabase
For data and sign-in, Supabase gives us a Postgres database, authentication and file storage without running our own servers. Row level security lets us write access rules in the database itself, so each user only sees their own data. Because it is Postgres underneath, the data stays portable.
See it for your project
Pick a type of project to see what we would start with:
When to break the rule
Defaults are a starting point. A product that relies on the camera, background audio or heavy offline sync may need native code for part of the app. A site with thousands of products may need a commerce platform instead of a static build. If that's the case, we say so in the proposal, before you pay for anything.
