Founding Engineer

Instockrx — United States · Posted ~2 hours ago

Lead Full-time Remote

Skills

Software engineering Product development Customer development Hypothesis testing Rapid experimentation Technical problem solving

🔓 Log in to save this job, tailor your resume & track your apply process — 7 days free, no card needed.

Log in to add to target list

Summary ✨ AI‑Generated

Join a growing healthcare technology company as a founding engineer in a remote, full-time role. You will work at the intersection of engineering and customer development, testing hypotheses directly with users and partners, building experiments, and turning validated problems into practical technology solutions.

Highlights

Remote, full-time founding engineering role in a profitable, rapidly growing healthcare technology business, with substantial ownership of experimentation, customer discovery, and new product development.

Description

Founding Engineer, InStockRx Labs InStockRx · Remote (US) · Reports to our Chief Evangelist, who leads Labs · Full-time, W-2 About InStockRx InStockRx is the marketplace that lets pharmacies trade surplus inventory and source medications at a fair price — keeping good drugs from going to waste and giving independent pharmacies room to breathe against PBM margin pressure. More than 1,800 pharmacies are on the network. We are profitable, growing quickly, and closed a Series A earlier this year. What Labs is InStockRx Labs is our customer development function, in the Steve Blank sense. We do not write a plan and then execute it. We write down what we believe, then go outside the building and find out whether it is true. Every project starts as a hypothesis — that a particular kind of pharmacy, patient or partner has a particular problem, that they know they have it, and that they would change what they do to solve it. Those are assumptions, not facts, and no amount of internal discussion converts one into the other. The only thing that does is putting something in front of the people whose problem it is. So Labs runs the first two steps of customer development. Discovery: does this problem exist, and does anyone care enough to act? Validation: is there a repeatable way to reach those people and get them to say yes? Only when both are answered does a project graduate into mainline development, where the company builds it properly and spends real money acquiring customers. Most projects do not get there, and are killed — quickly, cheaply, and on purpose. That is the system working. We have graduated one so far: a patient-facing product that proved itself in Labs and is now a funded product line with its own Director of Product. The role You build the thing the customer reacts to. In customer development the hypothesis is worthless until someone outside the building responds to something concrete. A conversation about a slide gets you politeness. Something a pharmacist can put their hands on gets you the truth. Your job is to produce that object, fast enough that we learn while the question still matters. The point of the code is not to be a product. It is to be real enough, in the service of a specific experiment, that the reaction it provokes can be trusted. You will work alongside a Customer Development Lead who finds the people to put it in front of and reads what their behaviour means. What you'll own The build, whatever the current experiment needs. Web, mobile web, a convincing front end over a fake back end, an integration stub, a working slice of something real. You choose the shortest path to a genuine reaction.The judgement call on “real enough.” Knowing which part of the thing is under test and must be solid, and which part can be held together with tape. Getting this wrong in either direction wastes the experiment — over-build and we learn slowly, under-build and the reaction is to the prototype rather than the idea.Speed. Experiments run in weeks, not quarters. The cost of being slow is not a late release — it is a decision the company makes without evidence.Being in the room. You will watch people use what you built, hear what they say about it, and help work out what it means. This is not a role where requirements arrive by ticket.Killing things. Writing the honest note that says this did not work, here is what we learned, here is what it cost us to find out.Handing over the winners. When something graduates, making sure the team that rebuilds it properly understands what was learned, what was real, and what was scaffolding. What success looks like in your first year Several experiments have run end to end, each producing a clear answer rather than an inconclusive shrug.Most of them were killed, fast, and nobody is sorry about it.At least one has been promoted into mainline development with enough evidence behind it to justify the investment.No experiment failed because what you built was too rough to judge, or arrived too late to matter.The company has made decisions it would not otherwise have made, because of something you put in front of a customer. What makes you a fit Senior and genuinely full-stack. You can take something from an empty repository to a working thing a stranger can use, by yourself, without waiting for anyone.You have built things real users touched, early. Prototypes, MVPs, pilots, founding-engineer work. Not just production systems that were already specified by the time they reached you.You are unsentimental about your own code. Most of what you write here will be deleted, and that is the job working correctly rather than failing. If that idea bothers you, this role will make you miserable.You can tell throwaway from foundation. Some of this graduates. Knowing when to write something you would be happy to hand over, and when to cut every corner, is the core skill.You can talk to customers. Pharmacists, pharmacy staff, and — increasingly — patients. You do not need anyone to translate for you, and you can tell the difference between what a user says and what they do.Comfortable working alongside an outsourced team. Our product engineering today is delivered by a long-standing partner team. Labs is different: you are in-house, and you are the one writing the code.Pharmacy or healthcare experience is a plus, not a requirement. The domain is learnable and we have plenty of people who know it. What this role is not Production engineering. No SLAs, no on-call, no five-year maintenance horizon.A team lead role. There are no direct reports, and this is not a management track today.A place to perfect an architecture. The experiment is the deliverable, not the codebase.A role for someone who needs their work to survive. Most of it will not.The mainline product team. Labs hands off to them; it does not replace them. Compensation We are profitable and we lead with cash. Your salary is not a bet on runway. Base salary: $160,000 - $205,000 depending on experience. We pay more for candidates whose experience warrants it — tell us what you bring.Equity: a meaningful grant.Performance bonus tied to company performance.Plus full benefits and a fully remote setup. How to apply Apply with your resume and a short note about something you built quickly to answer a question — what the question was, what you built, what you found out, and whether the thing survived.