What is the Happydance tech stack, and where is the debt?

Most tech stack pages are a logo wall. This one explains why each choice was made, what you would actually learn working in it, and, because this site runs on the Sell The Truth principle, where the technical debt genuinely is. If you are the kind of engineer who asks "yes, but what state is the codebase really in" in interviews, this page is for you.

Why TypeScript and React on the frontend?

TypeScript everywhere on the frontend because a multi-tenant platform serving enterprise clients cannot afford the class of bugs that types catch for free. React because the product is fundamentally a system of configurable, composable careers site experiences, easy-apply overlays, conversational navigation, analytics dashboards, and component-based UI is the honest fit, not a fashion choice.

What you would learn here that you might not elsewhere: building one frontend that renders correctly, performs well and passes WCAG 2.2 AA for dozens of enterprise brands at once. Theming, accessibility and performance stop being nice-to-haves and become the actual job. Engineers who join from single-brand products consistently say the multi-tenant discipline made them sharper. If that side of things is your favourite part, the frontend engineer role leans hardest into it.

Why both Node.js and .NET on the backend?

Honest answer: partly history, partly fit. The platform grew out of an agency world where .NET was the enterprise workhorse, and those services remain solid, well-understood and in no hurry to be rewritten. Newer services, especially anything close to the frontend or the AI layer, tend to be Node.js and TypeScript, so full-stack engineers can move across the boundary without changing languages.

Is a two-runtime backend the textbook-pure choice? No. Is it a reasonable trade-off for a platform that ships weekly to clients like National Grid and General Motors without drama? Yes, and we would rather run two boring, reliable runtimes than stage a heroic migration for the sake of a tidier diagram. You would learn both, and more importantly you would learn the judgement of when a rewrite is worth it and when it is vanity.

Why Azure, Terraform and GitHub Actions?

Azure because our enterprise clients live there, their security teams trust it, and meeting their compliance requirements is a first-class feature of the product, not an afterthought. Terraform because every environment is code-reviewed infrastructure, no snowflake servers, no tribal knowledge about which box does what. GitHub Actions because CI/CD should be close to the code and visible in the pull request where the conversation is already happening.

For a platform-inclined engineer, the learning here is scale of a particular flavour: not billions of requests, but hundreds of tenants, each with an enterprise brand's expectations of uptime, isolation and auditability. Multi-tenant infrastructure at that standard is a genuinely transferable skill, and it is the daily bread of the platform engineer role.

How does the AI layer actually work?

The AI features, conversational navigation, AI content generation, smart SEO automation, bias detection against 80 criteria, are built on LLM APIs with structured data pipelines underneath, rather than on models we train ourselves. The pipelines are the unglamorous secret: clean, well-structured careers data in, which is what makes the AI discoverability and answer-engine features reliable enough to sell to enterprises.

This is the fastest-moving part of the codebase and the most honest place to set expectations. Model versions change under us, provider behaviour shifts, and patterns that were best practice eight months ago get replaced. Engineers who enjoy that churn find this the best seat in the house, because you are shipping applied AI to millions of real candidates, not writing thought pieces about it. Engineers who need a settled, finished specification find it wearing. The how we work page explains how we keep that churn from becoming chaos.

Where is the technical debt, honestly?

Everywhere has debt. Here is roughly where ours is, stated plainly so you can decide with your eyes open:

• Older .NET corners. Some long-serving services predate our current standards for testing and observability. They work, they are stable, and improving them is scheduled rather than aspirational, but you will touch code older than the company's current taste.
• Frontend inconsistency at the edges. The core component system is strong; some client-specific customisations from earlier years are less elegant, and consolidation is ongoing sprint by sprint.
• The AI layer's moving ground. Abstractions around LLM providers have been rebuilt more than once as the ecosystem shifted, and will likely be rebuilt again. That is the cost of building at the frontier with someone else's models.
• Test coverage is uneven. Strong where the platform is newest, thinner in the oldest paths. New work ships with tests; backfilling the old paths is steady, unfinished work.

What we can say truthfully: debt here is acknowledged, mapped and paid down on purpose, with refactoring time inside sprints rather than in a mythical "later". What we will not claim: that it is gone.

What would you actually learn in this stack?

Concretely, over a year or two here you would deepen: production TypeScript across frontend and backend, React at multi-tenant enterprise scale, accessibility engineering to WCAG 2.2 AA as a habit rather than an audit panic, Azure and Terraform in a real compliance environment, CI/CD ownership through GitHub Actions, and applied LLM engineering with structured data pipelines, which in the current market is one of the most valuable lines a software engineer can honestly put on a CV.

Just as valuable is what the environment teaches: how to ship fast without breaking enterprise trust, and how to tell the difference between debt worth paying down and debt worth living with. A typical week of using all of this is laid out in what a software engineer here does day to day.

Frequently asked questions about the stack

Do I need to know both Node.js and .NET to get hired?

No. Strong engineers in one backend runtime pick up the other here. We hire for fundamentals and judgement, then let the codebase teach you its second language.

Do you train your own AI models?

No. We build on LLM APIs and invest our effort in the structured data pipelines, evaluation and product design around them. For a product company of our shape, that is the honest engineering choice.

How modern is the codebase really?

Mixed, like every platform that has paying customers and a history. The newest services and the core frontend are in good shape; some older .NET paths and early client customisations are not, and improving them is planned work, not denial.

Can I influence technology choices?

Yes, through the same route as everyone else: a written proposal, a squad discussion, and sometimes a hack day prototype. Several current pieces of the stack started exactly that way.

---

If you read the debt section and felt curiosity rather than dread, you are probably our kind of engineer, and the open roles will show you where that curiosity gets paid. To see how a squad turns this stack into shipped product every fortnight, read how we work.