I built a freelance tracker boilerplate in one evening with Cursor — here's the code and the monetization plan
I've been trying something for the past few weeks. Pick a specific problem, build a working full-stack app with Cursor, package the source code, sell it on Gumroad. No SaaS, no subscriptions — just source code people can download and run themselves.
This week I finished the second one: FreelanceFlow.
What it does
Tracks clients, projects, time entries, and generates printable invoices from the browser. Dashboard shows earned this month, outstanding invoices, active projects, hours logged. 12-month revenue chart included.
Nothing revolutionary. But it's a complete working app with a real database, a real API, and a UI that doesn't look like a tutorial project.
Live demo: https://freelanceflowweb-production.up.railway.app
The stack
React 19 + Vite + Tailwind v4 + shadcn/ui on the frontend. Express 5 + TypeScript + Drizzle ORM on the backend. PostgreSQL via Supabase free tier. OpenAPI spec with auto-generated React Query hooks via Orval. pnpm workspaces monorepo.
Cursor did most of the actual coding. I directed, reviewed, fixed bugs, made architecture decisions. Maybe 10% of the code is mine by hand.
The monetization angle
Full source code on Gumroad for $39. MIT license — use it commercially, build on it, white-label it, whatever.
There's also a PDF guide included covering how to add Stripe payments, how to turn it into a multi-tenant SaaS, and what that realistically looks like revenue-wise.
Gumroad: https://ibrh96.gumroad.com/l/bcsufq
Honest state of things
My first product, SubSaver (a subscription tracker), is also live and also hasn't sold yet. So I'm 0 for 2 right now. I'm sharing anyway because I think the process is worth documenting even before there's a win to report.
The freelance tracker space has a lot of free options. The person I'm hoping buys this is a developer who wants to skip the 2-3 days of boilerplate setup and get straight to building their own version of it. That's a specific person. I don't know how many of them are looking for this.
Two questions for anyone who's done this before:
- Is $39 the right price for a source code boilerplate? Feels low to me but I also have zero sales data to go on.
- Did IH posts actually drive traffic for you, or was it mostly other channels that converted?
managing the architecture while letting cursor handle the grunt work is a solid execution loop.
$39 is honestly too cheap for a full react 19 + drizzle orm setup like you detailed.when full-stack code is priced that low, devs automatically assume it's just a buggy tutorial repo clone. bumping it to a clean $49 signals actual production-ready value.
ih posts are killer for community feedback, but they rarely drive direct sales conversions. your target buyer looking to skip 3 days of config setup is usually actively searching specific subreddits or technical dev.to logs.
the freelanceflow dashboard UI looks super slick. keeping it real about the 0 for 2 state is pure grit."
Appreciate the pricing take — already bumped it to $49 after seeing the same signal from a few people. You're right about IH vs search-led channels, that's exactly where I'm focusing now. Reddit karma building at the moment, dev.to posts next. The "buggy tutorial repo" perception at $39 is real, didn't think about it that way until I started getting this feedback.
The positioning feels clearer than the product category: “skip 2-3 days of boilerplate and start from a working freelance app” is the real promise.
For pricing, I’d probably test two tiers instead of only asking whether $39 is right:
That lets you learn whether buyers just want code or actually want a faster path to a sellable variant.
For channels, I’d expect IH to be better for feedback than conversion. Search-led channels might convert better: “freelance tracker template”, “invoice app source code”, “SaaS boilerplate for freelancers”, etc. The buyer is probably already looking for a shortcut.
The two-tier idea is interesting. Holding off on tiers until I see the first sale on the base product — want to validate demand before adding complexity. But the extension recipes angle (Stripe, multi-tenant, invoice PDF) is actually useful framing for a future tier. Bookmarked. Search-led is exactly where I'm pointing now, "invoice app source code" type queries.
This is a strong direction because you are not just building another content helper. The sharper idea is that a founder’s existing work can become an inbound loop without them having to manually turn every update into content.
The part I would pressure-test early is the brand frame.
SubKitt works for v1, but it still feels a bit like a toolkit. If the product starts becoming “the system that turns my work into users,” the name may need to carry more platform weight than SubKitt can.
That matters before launch surfaces harden: emails, GitHub connections, landing page copy, user memory, and founder referrals all start locking the brand in.
For the bigger platform direction, Xevoa .com feels cleaner to me. Short, serious, workflow/platform-like, and broad enough to carry distribution, inbound, and automation without sounding limited to content drafts.
Not saying change it today. Just saying if this becomes more than a v1 experiment, the brand shell is worth deciding before product memory hardens around SubKitt.
Interesting name thoughts, but I think you might have meant this for a different post — SubKitt/Xevoa isn't something I'm building. FreelanceFlow is a self-hosted freelance tracker boilerplate. Happy to answer any questions about that if you have them.
You’re right, my mistake. I mixed up the thread context there.
FreelanceFlow being a self-hosted freelance tracker boilerplate is a different angle entirely. Appreciate you clarifying.
You’re right, my mistake. I mixed up the thread context there.
FreelanceFlow being a self-hosted freelance tracker boilerplate is a different angle entirely. Appreciate you clarifying.
Honestly, the 'zero views' phase is where most solo founders quit. Don't sweat a quiet launch. Instead of chasing viral traffic, focus on writing 3–4 hyper-practical case studies showing exactly how your tool solved a specific problem. Treat distribution like code—commit to it every single day, and let SEO do the heavy lifting over time.
The case studies angle is something I've been circling around without naming it properly. I've written deploy logs on dev.to — specific errors, exact fixes, what broke on Railway at 2am — but framed them as build stories rather than "here's the problem this tool solves for you." That's a real difference and I think you're right that the latter converts better.
The daily commit to distribution is the harder part. Building has a feedback loop: you write code, something works or it doesn't. Distribution is quieter. A dev.to post goes up and you wait three weeks to see if it did anything. I'm still building the muscle for that kind of patience.
Going to try the case study format on the next piece. Something like "how I tracked client payment delays that cost me X" rather than "here's how I built FreelanceFlow." Different entry point for someone searching.
Algorithm shadowbans or getting kicked off platforms is basically a rite of passage for indie hackers now. It sucks, but it forces you to look elsewhere. Forget chasing viral tweets. Go where people actually read long-form stuff, like Dev.to or Medium. One deeply practical tutorial solves a real problem, ranks on Google, and brings in way cleaner traffic than 50 rushed posts anyway.
The "one practical tutorial > 50 rushed posts" framing is something I keep having to re-learn. I've been writing build logs on dev.to but framed as "here's what I built" rather than "here's how to solve X problem" — which is a different search intent entirely. The tutorial that ranks is the one that answers a specific question someone's already typing. Still figuring out which questions my tools actually answer for people, but that's probably the right place to start.
the price question keeps coming up, but the angle nobody's asked: what security defaults ship in the boilerplate? whoever buys this inherits whatever you set. with supabase + drizzle + the multi-tenant SaaS guide on top, the spots that usually bite are RLS being off, JWT stored on the frontend, and invoice URLs being guessable. if those are already locked down, that's a real reason to charge more than $39. if not, that's worth fixing before more buyers ship them.
Good call — RLS is enabled on all Supabase tables by default in this setup, JWT is httpOnly cookie (not localStorage), and invoice URLs use UUID IDs not sequential integers. Happy to share the schema if you want to dig in.
nice, that's the boring stuff most boilerplates skip. one thing worth double-checking with RLS-on-by-default: that every new table actually gets a policy, not just RLS flipped on. an enabled-but-policyless table fails closed in a way that looks like a random bug, and the tempting fix is a quick allow-all that never gets removed. UUID invoice ids are the right call. would read the schema if you post it.
Here's the schema if you want to dig in: github.com/ibrh96-prog/freelanceflow
The RLS point is fair — I've got permissive policies on all four tables right now, which is fine for a self-hosted single-user setup but would need proper user-scoped policies before anyone runs this multi-tenant. That's intentional scope for v1, but worth calling out in the README more clearly.
makes sense for v1, and yeah, README is the right call. what i'd watch for: someone forks this for an actual SaaS, app already works, so nobody re-reads the policies. then two accounts can see each other's rows and that's the first anyone notices. i'd stick the warning in the schema file itself, right by the policies. README's easy to skim past.
That's a better place for it, you're right. A comment right above the policy definitions is harder to miss than a README section — especially when someone's moving fast and skimming. Going to add it as a TODO comment in the next push. Appreciate the catch.
Interesting approach, building and selling boilerplates like this is a tough space right now.
I feel like $39 is actually fine, but only if people land on the page already knowing exactly when they’d use it.
How are people finding it so far, Product Hunt or search?
0 sales so far, testing Reddit and dev.to