AStarted by AXIS Editorial
Asked by makers — answered by AXIS. We wrote this question in the words a maker would use; it does not quote or describe anyone.
The question: "I have about $15k saved for my AI app. Do I offer a developer equity, pay a contractor, or some mix? Everyone online just says 'it depends.'"
The answer. It does depend, but on three knowable variables — so here is the actual decision structure instead of the shrug.
Variable 1: is the technical work a project or a function? A project has an end state ("build the extraction pipeline, integrate billing"). A function is ongoing ownership ("keep this reliable, evolve the architecture, make technical bets"). Projects should be paid for; functions are what equity is for. Most first versions of AI apps in 2026 are projects — the AI tooling does more of the ongoing work than founders expect.
Variable 2: what does your equity currently buy? Equity compensates for risk with upside. Pre-users and pre-revenue, your equity is priced at its evidence, not its potential. $15k of paid contract work that produces a working v1 with real users can multiply what a later equity offer is worth — you'll give up less for more commitment.
Variable 3: what happens when it breaks at 2am? This is the honest case for a technical partner over a contractor: someone has to own production. If your app has paying users and no one on the hook for reliability, you have a liability, not a company. Contractors can be on retainer for this; equity partners are on the hook by construction. Neither is free.
The mix that keeps showing up in founder retrospectives as the least-regretted path: pay for the v1 (fixed-scope, milestone-based, IP assignment in writing), launch, get evidence, then recruit the ongoing partner — sometimes the same contractor, now with both sides informed. The most-regretted path, by a wide margin: 50% on day one to someone met two weeks earlier, no vesting.
Whatever you choose: vesting with a cliff, IP assignment, and the split in writing before meaningful work starts. Every time.
What's your situation — project or function? Write down which, and where the $15k currently feels riskiest.
Follow-up question: "What should $15k actually buy in contract work in 2026?"
With AI-assisted development, materially more than it used to — but scope discipline decides everything. Realistic: a production-grade v1 of a focused tool (one core workflow, auth, billing, deployment) from a senior freelancer working AI-assisted, at fixed scope. Not realistic: an app with five user roles, integrations, and 'admin dashboard' in the same budget. Structure it as 2-3 milestones with acceptance criteria, pay per milestone, and put IP assignment in the first document you both sign, not the last.
One asymmetry worth naming: founders systematically overvalue their pre-launch equity and undervalue their cash. $7.5k spent on a contractor is $7.5k, knowable and capped. 30% granted pre-launch is unknowable and permanent — if the app works, it becomes the most expensive engineering you ever bought; if it doesn't, it still complicates every future step (fundraising, sale, even shutting down cleanly). Spend the cheap resource first. Cash is almost always the cheap resource.
Follow-up question: "I already promised a developer 25% verbally and we've started building. How do I fix the paperwork without blowing up the relationship?"
The fix is standard and the conversation is easier than you fear, because the paperwork protects them too. Put the 25% in writing with 4-year vesting and a 1-year cliff, credit their months already worked toward the vesting start date (that is the good-faith move that makes the conversation land), and add mutual IP assignment. Frame: 'making what we agreed enforceable, for both of us.' A partner who resists writing down what was already promised is telling you something important early.
Follow-up question: "Does revenue-share instead of equity ever work for this?"
It can, for a narrow case: a builder who wants income, not ownership, on a product with real revenue mechanics — e.g., 20% of net revenue for 24 months, capped, in exchange for the build. It keeps your cap table clean and their upside real. Where it fails: pre-revenue (a share of nothing motivates no one) and as a substitute for the reliability function — when the incentive ends, so does the maintenance. Put a cap and an end date on it or it becomes equity with worse paperwork.