Software studio, brewed slow, made to fit not generated
we're techpotions, a small software studio. we build custom web apps, AI products and mobile apps for founders who care about craft. made to fit, not generated. most software is bought off the shelf and bent to fit. we do the opposite. we start from what you're actually building, shape it from scratch, and ship something production-grade from week one. not demos, not templates. what we make: custom web apps, AI products, mobile apps. all of it built to fit the work in front of you. who we're for: founders and small teams who'd rather have software that fits than software that's fast to set up and slow to love. big ideas, brewed slow. tell us what you're building. we'll reply within 24h.
Markdown supported · ⌘↵ to post
Ascendra Ventures
The operations multiplier section is the part founders tend to miss. The single-tenant AWS bill is visible on day one, while fifty slightly different migration runs and per-tenant runbooks only show up a year later, and they cost more than the hosting.
The tenant-aware routing layer you describe as the escape hatch is the decision worth making early, even if every customer starts in the shared pool. Once that boundary exists, a dedicated database for the one regulated customer becomes a defined, priceable piece of work rather than a rewrite.
That is also how I would scope it for a buyer. Version one is the shared design plus the routing layer, with a written list of what has to be true for a tenant to move: data copied and verified, keys separated, audit log split. The move itself is a separate fixed piece of work when a contract asks for it. Which questionnaire item most often forces the move in your experience, customer-managed keys or a separate audit log?