Backend Engineer/ Elixir

Most companies are stuck with software that doesn't really fit how they work, because building something custom used to cost too much. AI has made that cheaper. The problem is, cheap code adds up fast, and pretty soon nobody's actually read most of it. Your tests pass. Your monitoring is green. And somewhere in there, an invoice that was supposed to go out to the tax office just... didn't. Nothing crashed. Nothing errored. The code just never ran. We're not trying to make AI write better code. That's a fight we'd lose to the model providers anyway. We're starting from the assumption that there's going to be a lot of code, it'll be cheap, and nobody will fully know what's in it. Given that, what can you still promise a company? That's the actual question we're building an answer to. Right now that answer is a contract layer that checks deployed code against the process you actually declared. It's a way to know what the cheap code is doing. That's why we're looking for an Elixir Backend Engineer to help build it. Right now it's two of us. You'd be the third. EmpoweredHouse is Appunite’s startup. We already built the hard part: Shugyo, the intelligence layer, and we started the work on EmpoweredHouseOS, the runtime. What's missing is the layer between product and market - nobody is systematically turning what exists into awareness, distribution and inbound. What we offer Salary: 18,000 - 21,000 PLN net/month B2B - depending on your experience Remote first approach Full ownership of a single metric - community size - with no micromanagement Claude and automation tools as your standard working environment from day one What the job actually looks like day to day: You sit in on client workshops and help turn a messy business process into named events and rules. You design and build the contract and the backend behind it, and stick around to see how it holds up in production. You're not handed a spec by someone else — you're in the room when it's written. You build the tooling that makes the whole approach work: a generator that turns contracts into code, static analysis on compiled code, DSLs, macros, our own packages. You write business rules that a non-technical person, like an accountant, could read out loud and understand — and that also happen to double as tests. When something you built for one client turns out to be generic, you pull it into our shared library so the next client gets it for free. You push back on the architecture. The current architecture doc is still just a proposal, there are open objections, and the team has said outright that we don't have deep experience in this space yet. If you have a better idea, it goes in. You'll probably be a good fit if: You've worked as a backend engineer commercially, at a mid level. You care more about shipping something that actually works and is testable than about a clean test suite that doesn't catch the real bugs. You've written real backend code in Elixir — Ecto, PostgreSQL, background jobs with Oban — not just played with it. You're okay with architecture that isn't settled yet, deadlines that are real, and two client projects running at once on a two-person (soon three) team. Things will change under you sometimes. Nice to have, not required: You've built a DSL, written macros, or built a code generator or static analysis tool before. You like the idea of modeling a business as events and pulling the rules straight out of conversations with the people who run it. You've worked in fintech, accounting, or healthcare — it's not necessary, but it makes the client conversations easier. Our recruitment process Two steps, sometimes three: Culture & mission fit meeting with our Recruitment Team (about 45 minutes) Competency interview with team representatives (about 60 minutes) If we need another step, we'll tell you why before scheduling it. Either way, you'll hear a decision from us afterward — and hopefully, "welcome on board."