> Markdown version of [/jobs/ext/2241335-founding-engineer-ai-platform-neonvest](https://www.wearedevelopers.com/jobs/ext/2241335-founding-engineer-ai-platform-neonvest). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md). --- # Founding Engineer - AI Platform | neonVest - **Company:** NeonVest, Inc. - **Location:** United States (Remote available) - **Experience:** Expert - **Salary:** $18,000.0 - $24,000.0 - **Contract:** Permanent contract - **Skills:** PHP (Programming Language), Test Suite, Application Programming Interfaces (APIs), Artificial Intelligence, Amazon Web Services, Amazon Elastic Compute Cloud, CodeIgniter, Database Queries, Python (Programming Language), MySQL, TypeScript, Large Language Models, Data Layers, AI Platforms, Software Version Control, Airtable - **Published:** August 26, 2026 - **Apply:** https://arc.dev/remote-jobs/j/redirect/pfdxcp9pt2 ## About the Role 5-8 years building production software. You've shipped things people depend on and maintained them afterwards. Strong Python or TypeScript. The new service will be one of those. You've worked with LLMs and retrieval in production, not just demos. You know why RAG pipelines disappoint in practice and what to do about it. Research-level ML isn't needed; applied judgment is. ## Description We're rebuilding the core of our product - investor matching - as an AI-native service, and you'd be the person building it. Today, matching is a filtered database query. We want a system that reads a company, understands what an investor actually looks for, ranks the fit, and explains its reasoning. That's the first thing you'd build, and it's the piece that matters most commercially. The architecture will be specified before you start. Data model, service boundaries, how retrieval and reasoning fit together, how we evaluate it. You'd be building against a design rather than inventing one - and you'd be expected to push back on it where it's wrong. What you'd build, in order The investor data layer. Our investor data currently sits in two places: structured attributes in Airtable - sector, stage, cheque size, geography - and free-text descriptions plus years of match history in a MySQL database. First job is merging them into one clean, keyed dataset. Unglamorous, and everything else depends on it. The matching service. Embeddings over investor descriptions and company materials, retrieval to narrow the field, structured filters for hard constraints, and an LLM layer that reasons about fit and produces an explanation. Exposed as an API our existing platform calls. The evaluation harness. We have hundreds of past matches with known outcomes - meetings taken, feedback given, conversions. That's your ground truth. Every change to matching gets scored against it. "It feels better" is not a result. Then, incrementally, more of the platform. Once matching is live, we move the next capability across, and the next. Our existing PHP application keeps running the business throughout and gets switched off only when nothing calls it any more. And keeping the old system alive meanwhile. A CodeIgniter application from around 2021. Not glamorous, genuinely necessary - it carries real client and investor data., You can work in inherited PHP without wanting to rewrite it. You don't have to enjoy CodeIgniter. You do have to keep it running and resist touching what doesn't need touching. You can write. Small distributed team, mostly async. Explaining a technical trade-off to a non-technical founder in three sentences is part of the role. Nice to have * Vector databases, embedding models, evaluation frameworks * Experience replacing a legacy system piece by piece rather than in one jump * AWS - the platform runs on EC2 * Venture, fundraising or financial services exposure What you'd be walking into, honestly The existing application is about five years old and predates everyone currently here. There's no version control, no test suite, and until recently no copy of the code outside the production server. The operating system is out of support. We're saying so because it's the job. If that reads as a mess to avoid, we're the wrong place. If it reads as a clear runway - real data, real users, real revenue, and no incumbent architecture to argue with - it's the best kind of first ninety days. ## Related Videos - [The Vonage Trivia Voyage: Quiz Your Way to the Top!](https://www.wearedevelopers.com/videos/761-the-vonage-trivia-voyage-quiz-your-way-to-the-top) - [MySQL Protocol Features You Should Be Aware Of](https://www.wearedevelopers.com/videos/100267-mysql-protocol-features-you-should-be-aware-of) - [How To Test A Ball of Mud](https://www.wearedevelopers.com/videos/173-how-to-test-a-ball-of-mud) - [Developer Experience, Platform Engineering and AI powered Apps](https://www.wearedevelopers.com/videos/990-developer-experience-platform-engineering-and-ai-powered-apps) - [Coding for Good: Achieving social change with an app](https://www.wearedevelopers.com/videos/1645-coding-for-good-achieving-social-change-with-an-app) - [Postgres in the Age of AI (and Devin)](https://www.wearedevelopers.com/videos/1042-postgres-in-the-age-of-ai-and-devin) ## Related Articles - [Dev Digest 120 - Apple and peers](https://www.wearedevelopers.com/magazine/455-dev-digest-120-apple-and-peers) - [Navigating the AI Shift](https://www.wearedevelopers.com/magazine/629-navigating-the-ai-shift) - [How to Become an AI Engineer](https://www.wearedevelopers.com/magazine/331-how-to-become-an-ai-engineer) - [Dev Digest 137 - AI'm not sure about this](https://www.wearedevelopers.com/magazine/485-dev-digest-137-ai-m-not-sure-about-this) - [Dev Digest 132 - Binging WADFlix?](https://www.wearedevelopers.com/magazine/473-dev-digest-132-binging-wadflix) - [What is Software Engineering in the Age of AI?](https://www.wearedevelopers.com/magazine/640-what-is-software-engineering-in-the-age-of-ai)