Technology · 03 Back-End Platforms
Seven runtimes, three API styles and the plumbing around them: sign-in, queues, caching, file storage, email and SMS, rate limits. We recommend each one for a reason you can repeat to your board, and we say plainly what it costs to hire for later.
Updated September 2026 You own everything Reply within one business day
$oldevs deploy --env production
✓Build passed · 212 tests · 0 warnings
✓Migrations applied · postgres 16
✓API v2 healthy · 142ms p95
→Rolling out to 3 regions…
OlDevs, a full-stack studio in Vancouver, chooses a back-end runtime by asking who will maintain it after launch, where it must be hosted and how much change the client expects to fund.Node.js with TypeScript is the default for product teams, Python for data and AI services, PHP with Laravel or WordPress for content-led sites, and Go, .NET, Java or Rust when existing staff or performance needs call for them.
Key facts
03 · Back-End Platforms
Each card names the situation where we reach for the platform and the maintenance bill that arrives with it.
Right when one team owns both front end and back end, and shared types between them save real effort. Hiring afterwards is straightforward across Canada. The later cost is dependency churn: we pin the LTS line, audit packages every quarter and keep the framework surface small so upgrades stay boring.
Right when the product leans on data pipelines, machine learning or scientific code, or when Django's admin gets an internal tool live quickly. Python 3.13 and 3.14 are current at the time of writing. The later cost: async discipline and type hints need enforcing or the codebase drifts into two styles.
Right for content-led sites, membership portals and commerce where editors need a mature admin and hosting must stay inexpensive. We build on the PHP 8.4 and 8.5 lines. The later cost: plugin sprawl on WordPress and a Laravel major upgrade roughly every year, both manageable under a modest retainer.
Right for high-throughput services, command-line tools, network utilities and anything shipped as a single static binary onto a customer's own servers. The language is small and reads the same in every codebase. The later cost: a thinner local hiring pool than Node or Python and more hand-written code for web features.
Right when the client already runs Windows or JVM estates, has an IT department fluent in C# or Java, or needs long vendor support windows and audited libraries. The later cost: heavier build tooling and larger memory footprints, offset by decades of stable APIs and a deep enterprise hiring market.
Right for the one hot path that dominates your cloud bill or latency budget: media processing, matching engines, parsers, edge functions. We wrap it behind a plain API so the rest of the system stays in a common language. The later cost: slower builds and specialist hires, so we keep the Rust surface small.
Stack
Concrete tools, current at the time of writing; confirmed for your project at scoping.
Runtimes and frameworks
Compiled services
APIs and contracts
Identity and access
Jobs, queues and caching
Storage and messaging
What changed
What moved in this area and what it means for your build.
Oct 2025
The even-numbered release moved to LTS on the usual annual cadence. New OlDevs projects start on the newest active LTS line, and we schedule the upgrade for older projects before their line drops to maintenance-only status, so the security patches never lapse.
Oct 2025
The interpreter without the global lock is still an opt-in build, and much of the package ecosystem is catching up. We keep production on 3.13 unless a CPU-bound workload measurably benefits, and we test on 3.14 in CI so the move is routine when the time comes.
Nov 2025
PHP 8.5 continued the yearly cadence and .NET 10 became the supported line for enterprise work for the next three years. For clients this means a predictable upgrade calendar: WordPress and Laravel sites move to 8.5 once their plugins are ready, and .NET services get a long, quiet runway.
2025
A run of supply-chain attacks on popular JavaScript packages during 2025 pushed lockfile pinning, provenance checks and a short cooling-off period before adopting new versions into standard practice. Every Node project we deliver now ships with these guards and a documented dependency policy.
2025 to 2026
Major identity providers now offer passkeys alongside SAML and OIDC, and browsers handle them consistently. We enable passkeys as a second path rather than the only path, keeping password-plus-code flows for staff on shared or locked-down devices.
2026
More back-end code is now drafted with AI help, including by client teams after handover. The trend puts more weight on contract tests, typed interfaces and dependency audits than on any one language. We hand over a test suite and a review checklist so the guardrails outlive our engagement.
How we choose
If your team writes C# all day, we do not hand them a Go service. We start from the skills you have or can realistically hire in your region, then pick the runtime those people will keep healthy without us.
Canadian data residency, an existing Azure or AWS commitment, an on-premises requirement or a partner's private network all narrow the field. Some runtimes deploy as one binary; others want a container platform and a managed database nearby.
A portal that changes weekly needs a framework with fast iteration and a deep hiring pool. A billing engine that changes twice a year rewards a stricter compiled language and a longer support window. We ask how often you expect to fund changes.
Mostly waiting on databases and third-party APIs suits Node or Python. Heavy computation, large fan-out or tight latency targets push toward Go, .NET or Rust. We profile the real workload before we commit rather than guessing from the brochure.
Your identity provider, ERP, CRM and legacy databases set constraints. If single sign-on lives in Microsoft Entra ID and reports live in SQL Server, a .NET service is often the shortest path. We build around what you own, not around our habits.
We check each framework's licence, its published end-of-support dates and its release cadence, then write them into your handover documentation. You should know, before signing, when the next mandatory upgrade lands and roughly what it involves.
Who it's for
Whether the audience is a customer, a member, a citizen, or your own team, the choice has to hold up under real use.
Back ends that fit an existing estate: SAML or OIDC into your identity provider, audit logging, rate-limited partner APIs and services your internal developers can own. We favour .NET, Java or TypeScript when that is what your IT department already runs.
Member portals, grant systems and public services with Canadian hosting, bilingual EN/FR content, WCAG 2.2 AA interfaces and procurement-friendly documentation. Django and Laravel give editors a capable admin without a licence bill.
One platform, many locations: multi-tenant data models, per-location permissions, queued reporting jobs and integrations with point-of-sale and booking systems. Node.js or Laravel keeps the codebase in a language that regional agencies can support.
A runtime your first hires will know, an API contract investors' technical advisors can read, and background jobs, email and file storage set up properly from the first sprint. TypeScript across the stack usually keeps a small team moving fastest.
Related technology
Modular monolith or microservices, queues or direct calls, one tenant or many: the shape of a system decides…
Explore06Your database outlives every framework in front of it. We default to PostgreSQL, add Redis, document stores,…
Explore05AWS, Microsoft Azure and Google Cloud, plus Vercel and Cloudflare where a smaller footprint fits. Canadian…
ExploreFAQ
Usually the one your future maintainers already know. For most product teams that is Node.js with TypeScript, because the same people can work on the front end and the hiring pool is large. Choose Python if data science or AI is central, PHP if the site is content-led, and a compiled language only when the workload or your existing staff justify it.
All three, but we default to REST with an OpenAPI 3.1 contract because every partner, tool and language can consume it. GraphQL earns its place when many screens need different slices of the same data and a front-end team wants to move without back-end changes. gRPC is for service-to-service traffic where binary contracts and streaming matter.
We never write our own password storage. Sign-in goes through a standards-based provider: OpenID Connect for apps and APIs, SAML 2.0 where a corporate or government identity system requires it, and passkeys for phishing-resistant staff logins. Sessions, refresh tokens and role checks are handled in the back end, and every decision is logged.
They are part of the build, not an afterthought. Long-running work moves to a queue with retries and dead-letter handling, uploads go straight to object storage behind signed URLs, and email or SMS goes through a transactional provider with delivery tracking. You get dashboards for each so a failed job or bounced message is visible, not silent.
Yes. We start with a read-only review: dependency ages, test coverage, unsupported versions, secrets handling and the deployment path. Then we propose a stabilisation plan before any feature work. Rewrites are rare; most systems are better served by upgrading in place and adding tests around the parts that change most.
Additive changes ship without a version bump: new fields, new endpoints, new optional parameters. Breaking changes get a new major version in the URL or header, a published deprecation date and a migration guide. Rate limits and usage logs per API key tell you exactly which partners still call the old version before you retire it.
That question shapes the choice. Node.js, Python, PHP, Java and C# all have deep hiring markets in Canada and abroad. Go and Rust are easier to hire for than they were, but we still confine them to the services that need them. Every handover includes a runbook, an architecture note and the reasons behind each choice so a new hire is productive in the first week.
Let’s connect
Tell us what you’re building. We’ll reply within one business day with recommended platforms, structure and a tailored quote — no obligation.