Why this role exists
AIApply is scaling fast. What we need now is product clarity, ruthless prioritisation, and fast shipping — not process for process’ sake.
This role is for a Product Engineer: someone who can own product problems end-to-end, make strong decisions, and build the solution themselves in Laravel.
If you describe yourself primarily as a “stakeholder manager” or someone who “aligns teams,” this isn’t the role.
If you like owning outcomes, shipping weekly, and sweating details, keep reading.
What you’ll own
You will own core product surfaces from problem → solution → impact.
Examples:
* Activation & onboarding flows (first 24h experience)
* Retention loops (day 7 / day 30)
* Auto-Apply workflows (quality, confidence, transparency)
* Core dashboard UX and system clarity
* Monetisation & plan boundaries (what users actually understand)
You will:
* Identify the highest-leverage product problems
* Define the simplest possible solution
* Build it yourself (Laravel + frontend)
* Measure impact and iterate quickly
What you’ll do day-to-day
Product
* Turn fuzzy problems into clear, testable product bets
* Kill ideas that don’t move activation, retention, or revenue
* Write concise specs only when useful (often a few bullets is enough)
* Make trade-offs without needing consensus
Engineering
* Ship production-quality Laravel code
* Improve and extend existing systems (not rewrite for fun)
* Work directly with Stripe, analytics, AI workflows, queues, cron jobs
* Debug real user issues, not theoretical ones
Data & outcomes
* Think in funnels, cohorts, and deltas
* Obsess over activation, retention, LTV, and churn
* Use data to decide what not to build
* Own results, not just delivery
Required background
You must have:
* 5+ years experience with Laravel in production
* Strong SQL and backend fundamentals
* Frontend competence (enough to ship clean UX without hand-holding)
* Experience owning features end-to-end in a real product
* Product intuition grounded in user behaviour, not opinions
* Bias toward speed, clarity, and simplicity
You likely have:
* Worked at an early-stage or scaling SaaS
* Strong opinions about bad UX and bloated products
* Shipped things that materially moved metrics
* Little patience for bureaucracy
What we explicitly don’t want
* “Pure” PMs who don’t build
* Process-heavy frameworks without output
* Jira theatre and over-documentation
* People optimising for optics over impact
* People uncomfortable saying “no”