01 / core
stack
Storyblok + Astro are our core for content-led platforms. Cloudflare delivers at the edge; Rails supports the systems that need application data.
start with an audit- content
- Storyblok
- Visual editing for marketing teams
- frontend
- Astro
- Static HTML, with islands when needed
- edge
- Cloudflare
- Caching and delivery close to visitors
- systems
- Rails + PostgreSQL
- Application data and transactions
today
The defaults we would defend in writing.
02 / content alternative
Sanity, supported
Sanity suits product-like content when developers shape the editing experience. Storyblok remains our default for editorial sites.
03 / frontend
Astro
Astro ships almost no JavaScript on content-heavy sites. The budget still applies after launch.
04 / backend
Rails + Postgres, in support
Rails and PostgreSQL handle relational data and transactions. Redis and Sidekiq run background jobs.
05 / deploy & edge
Kamal on your servers, Cloudflare at the edge
Reproducible containers on contracts you already hold, with edge caching and instant purges worldwide.
the inventory
Each layer has a clear job. The detailed theses explain where it fits, its tradeoffs, and when we choose something else.
01 / stack layer
core
Storyblok + Astro — the default we build marketing sites on.
02 / stack layer
frontend
What keeps the core typed and on brand?
03 / stack layer
backend
Where does relational data live when the platform needs it?
Ruby on RailsUse when data is relational and failure has a cost; choose Astro for static marketing surfaces.PostgreSQLUse as the system of record for anything relational; pair with Redis for ephemera.Redis + SidekiqUse for webhooks, syncs, and emails; never fire third-party calls inline in requests.
04 / stack layer
edge
What else do we support and run in production?
SanitySupported alternative to our Storyblok core — use when content is product-like and developers shape the editing experience.Docker + KamalUse when you own VPS or bare metal contracts; keep Vercel only where preview workflows earn it.Cloudflare WorkersUse for caching, redirects, and edge personalization; keep business logic in Rails.
how we work
01no vendor lock-in
We recommend the platform that fits the work. If your current stack meets the requirements, the roadmap says to keep it.
02paid for delivery
Clients pay us to build and run the system. Vendors do not pay us for placement.
03you keep the infrastructure
Your codebase, deployment pipeline, and cloud accounts stay under your control. We document the setup for your team.
legacy
Start from the migration path you already hold.
We model the cost of staying versus moving before recommending anything.
get a recommendation based on your requirements
In the audit we map your estate, model the cost of staying versus moving, and document the recommendation, so you can defend the choice internally, in writing.