Founding Software Engineer
--EVERJUST--
EVERJUST is a software factory. We build software products and take them to market. Two tracks run on everything: BUILD makes the product, GTM gets it adopted. This role owns architecture and delivery end to end — on the products we build for clients and the ones we run ourselves. You decide what gets built, not only how, and you are in the room when the scope is priced.
What you do
- Settle the architecture before feature code starts — data model, service boundaries, auth, deployment shape — and write the decision down so it survives the person who made it.
- Build in the client's own cloud and repositories from the first commit. Handover is a permissions change rather than a migration, and that only stays true if you hold the line from day one.
- Ship the whole path: schema, API, the surface a user touches, and the pipeline that puts it in production.
- Keep the build inside the printed price. A $9,650 storefront build is a $9,650 storefront build. An Enterprise Build starts at $25,000 and the scope has to be honest at that number. If it does not fit, say so before the estimate goes out and propose the version that does.
- Push back on scope. When a request costs three weeks and solves nothing, argue it out early, in writing, with the alternative attached.
- Work on our own products as well as client builds — EVERJUST.APP, CustomAgents, Custom Domain, FaceSmash — where you are the customer, the bug report and the fix.
What we look for
- Something you built that real people used: a repository, a live URL, a product that shipped. Our application asks for that instead of a cover letter, and we would rather read the code than the CV.
- Judgement about what not to build. Tell us about a feature you argued out of a project and what happened afterwards.
- You have taken a system from an empty repository to production and then lived with it — the migration, the failure at an awkward hour, the second year of it.
- You are comfortable in a cloud account you did not set up, in a codebase whose conventions are not yours. That is where most of this work happens.
- Strong SQL and relational data modelling. That one is a hard requirement. The rest of the stack you can pick up here if the judgement is there.
- You write clearly. Architecture decisions, scope arguments, handover notes and the reason a price is the number it is are all writing.
Nice to have
- Odoo, or any large opinionated platform you have had to extend rather than replace.
- Time spent close to the commercial side — pricing, scoping, or sitting across from the person who signs.
- Mobile shipped to a store, or identity and auth work that had to run in the browser.
- DNS, TLS and edge routing you can debug without first working out which layer is lying. Custom Domain is one of our products and it is exactly that work.
What it is like
The good part is how short the distance is between deciding something and it existing. Small team, and no account managers standing between you and the person who has to live with the result. You choose the architecture, you build it, then you watch GTM take it to market and find out whether anyone wanted it. Most engineering jobs stop at the first half.
The hard part is that the standards are whatever you set. Nobody is going to hand you a style guide or a test strategy. Client builds and our own products compete for the same week, and some weeks the client wins. Because the prices are published, a bad estimate is not absorbed quietly somewhere upstream — it comes out of the build you then have to deliver. When a decision is wrong it is wrong in production, and it is yours.
Not for you if
- You want a groomed backlog and a clear ticket. The first question here is usually whether the ticket should exist.
- You want a specialism protected — front end only, or infrastructure only. The work crosses every layer, including the parts you like least.
- You would rather not talk to the client. You will be in the room where scope and price are decided, and you will be the one explaining the trade-off.
- You only want greenfield. Much of this is extending a large platform that already has opinions, and living inside them.
- You need to own the cloud account and the repository. They belong to the client from the first commit; you work with the access they grant.
- You would not take a paid, time-boxed piece of our real backlog as part of being hired. That step is not optional. It is how the decision gets made, in both directions.