The short versionYou'd build new applications for a company that makes real things, with direct access to the people who need them, and you'd make the product and design calls yourself. You'd do it alongside a small team of engineers who are very good at this. The hard integration layer, ERP, warehouse management, and the existing service fleet are already covered. You own what gets built on top.
About the roleThree things make this different from most "full stack" postings, plus one that will rule it out for some people:
It's greenfield. You'd be building business tools from a clean slate. Modern stack, decisions still open. You are not inheriting a decade of someone else's shortcuts.
You'd have strong peers, not a vacuum. An SRE owns our delivery platform and GitOps practice. Another engineer owns the integration layer between our core business systems and everything else, along with the data pipelines feeding it. Both are excellent at what they do and aren't going anywhere. You'd own the applications built on top. You would have genuine ownership, and real peers worth arguing with when a decision is genuinely hard.
One expectation worth stating plainly: we want developers who extend those patterns, not just consume them. You don't have to own the platform, but you should be able to read it, add to it, and be trusted to do so.
This is a small team. Your work is visible and your judgment carries, and there's also nowhere to hide.
You'd learn the business, not just take orders from it. Requirements come from the department heads who need the software: purchasing, nutrition, operations, sales. They don't get filtered through a product organization, and they won't be. We don't have project managers and aren't planning to hire any.
This is the part of the job we care about most, so it's worth being direct about it. The people asking will describe what they think they need. The work is to absorb their process well enough to understand what they actually need, which is frequently different and occasionally the opposite. We have seen that change the course of a project, more than once. An application built from the first description tends to work for a quarter and then quietly stop fitting.
Plenty of capable developers can't do this, or don't want to. That's a legitimate preference and this is the wrong job for it.
The trade: no product manager to turn a vague request into a spec, no designer to hand you a comp, and light management. Nobody will assign you tickets or check your progress daily. If you build your own structure, that's freedom. If you need someone else to build it for you, this will go badly for both of us.
What you'll own- Architecture, API design, and user experience for the applications you build
- Turning business requirements into roadmaps and shipped code, including deciding what not to build
- Build and deployment automation: containerization, GitOps, fast and boring releases
- Application-layer infrastructure as code, extending our existing GitOps and deployment patterns rather than working around them
- The code quality and security standards that keep all of the above safe to move quickly in
How we buildWe're deliberately polyglot: several languages in production, more than one kind of data store, containerized workloads, GitOps delivery, infrastructure as code.
We aren't listing the specifics, on purpose. They change, and we'd rather hear how you choose tools than check whether you've used ours. What matters is that you've worked across enough languages and runtimes to know the language is rarely the hard part, and that you reach for the right tool for the problem t comfortable in.
How we work with AIWe use agentic AI development tools daily, and we've done the unglamorous part. Agent instructions, coding standards, and architecture decision records live alongside the code, so the tools produce work that fits our conventions instead of fighting them.
We'd want you to extend that practice, not invent one from scratch.
We're also clear-eyed about it. These tools make it easy to produce something that demos well and falls apart in six months, and we've watched it happen elsewhere. The conventions exist to prevent that. We'd rather you use them heavily and understand exactly what you shipped than either avoid them or trust them blindly. If you have opinions about where they genuinely help and where they quietly create problems, we want to hear them.
What we're looking forWe're not listing a number of years. What matters is what you've actually done:
- You've architected, shipped, and operated production systems, including being the one paged when they broke
- You've decided what to build, not only how, on at least one system that mattered
- You've learned a business process deeply enough to build something different from what was requested, and you were right
- You can weigh trade-offs and constraints on your own and defend the call afterward
- You've picked up someone else's deployment and infrastructure conventions and extended them, rather than routing around them or building a parallel path of your own
- You've made a UX call that shipped, turned out wrong, and fixed it
- You've shipped production work in more than one language and runtime, and can say why each was the right choice at the time
- You're comfortable across relational and non-relational data modeling, API design, and modern web architecture
If you can speak to those from experience, the number on your résumé isn't interesting to us.
