Why I Hire Full-Stack Engineers Who Care About the Physical World
I've read a lot of engineering job posts in the last year. Most of them describe the same job: build features on a web app, write tests, participate in code review, work in an agile environment. The stack varies. The problem domain is often left vague.
When I write a job post, I try to do something different. I try to describe the actual problem.
Not because it makes for better marketing — though it does — but because I've learned that the engineers who care about the specific problem we're working on are the ones who make the work better. And the specific problem we're working on is unusual enough that it's worth describing honestly.
What we're actually building
Alpha Deal builds software for affordable housing developers. Specifically, for the pre-development phase — the work that happens before a project is financially structured, let alone under construction.
That work is currently done in spreadsheets, through phone calls, and by relying on institutional knowledge that lives in a handful of people's heads. Our job is to build tools that surface the right information at the right moment — subsidy program eligibility, zoning constraints, capital stack scenarios — so that development teams can evaluate more sites and make better decisions faster.
The user is a senior acquisitions director or real estate analyst who has spent years learning a genuinely complex domain. They know things we don't. The software we build has to be good enough to be useful to someone who could do this work without us.
That's a different product challenge than building a consumer app. It demands a different kind of thinking.
The engineering problems are real
I'll be specific, because vagueness about technical challenges is one of the things that makes most engineering job posts useless.
Zoning code abstraction. Zoning codes are written in legal language, structured inconsistently across thousands of jurisdictions, and updated irregularly. Translating them into parameters a feasibility model can actually use — height limits, FAR, permitted uses, parking minimums — is a hard problem with no clean solution. We've made meaningful progress on it. There's significant work left.
Subsidy program modeling. The interaction between 9% LIHTC, 4% LIHTC with tax-exempt bonds, state tax credits, HOME funds, CDBG, opportunity zone equity, and local soft loans creates a combinatorial problem that's genuinely complex. Different combinations produce different amounts of subsidy, have different compliance requirements, and work for different site profiles. Building a system that models this accurately — and surfaces the relevant combinations for a given site — requires both data infrastructure and domain knowledge working together.
Multi-variable feasibility. A feasibility analysis isn't a single calculation. It's a set of scenarios, each with different assumptions about unit mix, AMI targeting, financing terms, and construction costs. Building a UI that lets practitioners explore those scenarios quickly — without oversimplifying what's actually complex — is a product challenge as much as an engineering one.
Practitioner-grade UX. Our users are not early adopters. They're not forgiving of tools that are slow, unclear, or opaque about their limitations. Building software that earns trust from domain experts requires a different standard than building software for general consumers.
Why the physical-world angle matters to us
There's a category of engineer who cares about what happens after the code ships. Not in an abstract sense — not just "users" as a concept — but about the physical outcomes that the software affects.
In our case: affordable housing that gets built because a development team had better information. Sites that get evaluated instead of passed over because the team couldn't justify the research time. Projects that reach financing because the capital stack was modeled more thoroughly than it would have been otherwise.
These outcomes are concrete. They involve real buildings, real neighborhoods, real families. And they're only possible if the software works well enough that practitioners actually use it.
I hire for engineers who find that orientation motivating — not because it's required to do the job, but because it tends to produce better product decisions. When you care about the downstream outcome, you make different choices about what to build and how to build it.
What working here actually looks like
We're early. That means high ownership, genuine ambiguity, and the kind of direct feedback loop between engineering and product decisions that disappears as companies scale.
It also means the problems aren't fully solved. We're still figuring out parts of the data model. There are technical decisions we'll make in the next six months that will shape the architecture for years. If you're someone who wants to work on greenfield problems with real stakes, this is that.
It also means we won't have everything figured out when you join. The codebase is young. Some things will be messier than you'd like. That's the trade-off for the ownership and the problem.
If you want a job where the technical challenge is clear, the users are real, and the thing you're building connects to outcomes you can actually see in the world — I'd like to talk to you.
We're hiring full-stack engineers who want to build serious software for a domain that matters. If the problems described here sound interesting to you, reach out.