Full Stack Developer

The short version You'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 role Three 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…