Corewell SystemsTechnology
What we build with, and why
This page is for the technical reader — a CTO, an IT manager, or the developer who will be asked whether we know what we are doing. Everyone else can skip it: what matters elsewhere on this site is what the software does, not what it is written in.
Two labels run through the list. In production means a system of ours runs on it today. We work with means we take engagements in it, but our own published systems do not feature it. We would rather you knew the difference.
Backend & APIs
Where the business rules live. Every rule is enforced here rather than in the interface, so it holds no matter which client calls it.
- ASP.NET Core / C#In production
Our clinical and equipment platforms — the systems carrying regulated data, audit trails, and full revenue cycles.
- Node.js / ExpressIn production
The booking-marketplace API: payments, availability, owner onboarding, and webhook processing.
- TypeScriptIn production
Strict typing end to end on our JavaScript services and front ends — fewer runtime surprises in production.
- PythonWe work with
AI/ML work, data processing, and reporting pipelines where the ecosystem is strongest.
- PHP / LaravelWe work with
Engagements on existing Laravel systems, and builds where the client's team already maintains PHP.
Web interfaces
Interfaces built for people doing a job under time pressure — a front desk at 8am, not a demo audience.
- ReactIn production
Operational dashboards, booking flows, and admin back offices.
- Next.jsIn production
Server-rendered applications and marketing surfaces where search visibility and first paint matter.
- BlazorIn production
A .NET web platform where sharing types between server and interface removed a whole class of bugs.
- Razor / server-rendered .NETIn production
The clinical platforms' interface layer, paired with vanilla ES modules for fast, dependency-light screens.
- AngularWe work with
Engagements where a client's existing front end or in-house team is already Angular.
- Tailwind CSSIn production
Design systems that stay consistent across hundreds of screens without a growing stylesheet.
Mobile & devices
The parts of an operation that happen away from a desk — and sometimes on hardware doing exactly one job.
- Capacitor / IonicIn production
A companion clinical app sharing the same API as the web platform, so records never diverge.
- Native Android (Java/Kotlin)In production
Two purpose-built tablet applications in production: a lobby check-in station and a card-reader terminal.
- React NativeWe work with
Cross-platform apps where one codebase for iOS and Android is the right trade-off.
- FlutterWe work with
Cross-platform builds where the client's team or existing app is already Flutter.
Data
The part that outlives every interface. Modelled carefully, because a bad schema is expensive for years.
- SQL ServerIn production
Clinical and equipment platforms, including row-level security enforcing organisation isolation in the database itself.
- PostgreSQLIn production
The booking marketplace and a platform that runs the same release against either engine.
- Entity Framework CoreIn production
Data access with global query filters for multi-tenant scoping and interceptors that audit every write automatically.
- PrismaIn production
Typed database access on our Node services, with transactional writes across bookings, payments, and inventory.
- MongoDBWe work with
Document-shaped workloads where a relational schema would fight the data rather than describe it.
Real time, AI & payments
The parts clients notice most: screens that update themselves, documents that write themselves, and money that arrives.
- SignalR / WebSocketsIn production
Live schedule updates, consent notifications, and a desktop-to-tablet payment bridge — nine channels in one platform.
- LLM APIs (Gemini, Claude)In production
Ambient documentation, code suggestion, and extraction — always server-side, with identifiers stripped before any call.
- Stripe (incl. Connect & Terminal)In production
Card payments, marketplace payouts to third-party accounts, platform fees, subscriptions, and tap-to-pay on a tablet.
- EDI / clearinghouse integrationIn production
Electronic insurance claims with payer acknowledgements and remittances ingested and posted automatically.
- Cloud object storageIn production
Encrypted documents and media with signed, expiring links rather than public URLs.
Running it
Deployment is not the last step of a build — it is the first day of the system's actual life.
- DockerIn production
Reproducible builds, so what passed review is what runs.
- Vercel / Render / managed cloudIn production
Managed hosting where the workload suits it, with preview environments per change.
- Windows Server / IISIn production
On-premises and private-server deployments, including clients whose data cannot leave their own infrastructure.
- Scheduled backups & monitoringIn production
Encrypted backups to separate storage, health and readiness probes, and alerting — with restores exercised, not assumed.
How we choose
The reasoning behind the list
A stack is a set of trade-offs, not a badge. These are ours.
Boring technology, deliberately
We choose mainstream, well-supported tools with long support horizons and a hiring pool. A framework that is exciting this year and unmaintained in three is a liability we would be handing you, not a feature.
The stack follows the problem
Regulated data with heavy reporting and a long support life goes to .NET and SQL Server. A payments marketplace that must ship fast goes to Node and PostgreSQL. We do not have one hammer and we do not pretend otherwise.
One API, every client
Web, mobile, and purpose-built devices talk to the same interface, so every rule is written once and enforced on the server. Reimplementing logic per platform is how systems quietly disagree with themselves.
Nothing you cannot leave
No proprietary runtime, no closed data format, no dependency on us. The code, the schema, and the documented architecture are handed over. We build for the day you might want to run it without us.
Straight answers
Technical questions, answered plainly
What technical evaluators ask us before a build is agreed.
Which stack will you use for our project?
Whichever fits the problem, decided during design rather than before we have met you. Regulated data with heavy reporting and a long support life tends toward .NET and SQL Server. A payments-heavy platform that must ship quickly tends toward Node and PostgreSQL. If your team already maintains a stack, that carries real weight — software your people can support is worth more than software we prefer.
Can you work on our existing system rather than rebuilding it?
Often, and it is usually the cheaper answer. We take engagements on existing codebases in the frameworks listed here. A rebuild is worth proposing only when the current system genuinely blocks the business — not because it was written by someone else.
Do we get the source code?
Yes — the code, the database schema, and the documented architecture. We build on mainstream technology with a real hiring pool specifically so you are never dependent on us. There is no proprietary runtime and no closed data format anywhere in what we hand over.
Can the system run on our own servers instead of the cloud?
Yes. We have deployed to managed cloud platforms, cloud virtual machines, and on-premises Windows Server — including for organisations whose data is not permitted to leave their own infrastructure. We have also built systems whose same release runs against different database engines, so hosting stays a decision rather than a rewrite.
How do you handle AI without sending our data to a third party?
Identifiers are stripped from text before it reaches a model, calls are made server-side under our own keys, no data is used for model training, and every automated action is logged. Nothing a model produces becomes a record until a person approves it.
Bring your architect to the call
We would rather answer hard technical questions early than discover the disagreement halfway through a build.