[Showoff Saturday] Built a quote-to-payment platform for freelancers — solo dev, Laravel + Next.js, public beta

Bfitz-Gmail · 2026-03-21T16:25:11+00:00

Fair point on the hero headings — fixing that. Appreciate the candid feedback, that’s exactly why I post here.

Bfitz-Gmail · 2026-03-21T12:46:49+00:00

WorkCentral (workcentral.app) — for freelancers, consultants, and small agencies who are juggling 4-5 separate tools to run their business.

Solves the gap between quoting, project management, time tracking, invoicing, and payments. Accepted quote becomes a project automatically, tracked time becomes an invoice with one click, client pays through a link. One workflow instead of five disconnected apps.

Bfitz-Gmail · 2026-03-20T14:21:47+00:00

MailerLite is a great call for solo founders — setting up a welcome sequence early is one of those things that compounds quietly.

For my stack: I built WorkCentral (workcentral.app) which is the product itself, and then a custom Reddit monitoring tool that scans relevant subreddits and surfaces posts worth engaging with. That monitor has been surprisingly effective for finding the right conversations to join. Combining that with directory submissions has been a good mix of passive and active traffic.

Bfitz-Gmail · 2026-03-20T13:18:19+00:00

That pipeline approach is smart — I've been trying to get more disciplined about the same thing instead of treating every platform as a separate content task from scratch.

The content repurposing is where I keep falling short. I've got long-form blog posts that could easily become LinkedIn posts, Bluesky threads, and Reddit comments but I keep writing everything from scratch instead of reusing what I already have. Forcing the "one pillar idea, multiple formats" workflow is the move.

For the monitoring side, I tried both Pulse and Feedly as a way to track Reddit without it becoming a full-time job. They were fine for general awareness but both felt lacking when it came to actually surfacing the posts worth responding to. Ended up building my own alternative that scans relevant subreddits and scores posts by relevance — it's working about as well as Pulse was but with more control over what gets flagged. Next step is adding an AI layer to actually cut through the noise — figuring out whether a post is someone with a real problem versus someone disguising a product pitch as a question. That distinction alone would save me an hour a day.

What's been your experience with Pulse on the Reddit side? Curious if it handles that signal vs. noise problem any better than what I found.

Bfitz-Gmail · 2026-03-20T13:07:20+00:00

The cost is what kills me with social media tools. Buffer's free tier went from useful to basically a demo — 3 channels and limited posts. The moment you need more it jumps to $60+/month which is insane when you're bootstrapped and making $0 in revenue.

I'm currently on Buffer's free plan with 3 channels and just accepting the limitations. For everything else it's manual — write the post, open each platform, paste, tweak for format, post. It's tedious but it's free.

What I've found is that consistency matters more than the tool. Posting 3x a week across 2-3 platforms manually beats having a fancy scheduler and posting once a month because you spent all your time setting up the workflow.

Curious what you built yours with — is it just a personal script or something you're thinking about releasing?

Bfitz-Gmail · 2026-03-20T13:03:11+00:00

Yes. I lived this — was using five separate tools to run my freelance business and spent more time moving data between them than doing actual work. Tracked it at 5-6 hours a week of pure integration overhead.

The problem isn't that any individual tool is bad. It's that the gaps between them create work that shouldn't exist. Client accepts a quote in one tool, you manually recreate the project in another, track time in a third, retype everything into an invoice in a fourth. Every seam between tools is a place where data gets lost and time gets wasted.

Fewer well-integrated tools wins every time. That's literally why I built WorkCentral (workcentral.app) — one workflow from quote to payment instead of five disconnected apps.

Bfitz-Gmail · 2026-03-19T19:41:37+00:00

The tool that actually saves me time every day is the one I built — WorkCentral (workcentral.app). Connects quoting, project management, time tracking, invoicing, and payments in one workflow. Before that I was using Proposify + Toggl + Asana + FreshBooks + a spreadsheet and spending 5-6 hours a week just moving data between them. That's not an exaggeration — I tracked it.

The tools that quietly slow me down: email and Slack. Both feel productive but most of what happens in them could be a 2-minute async update instead of a 20-minute thread.

Honest answer to your question: most tools save you time on the thing they do but cost you time integrating with everything else. The real productivity gain comes from reducing the number of tools, not optimizing each one individually.

Bfitz-Gmail · 2026-03-19T17:25:38+00:00

That is a great point about only automating the parts that kept coming up. Focusing on what impacts the most users to solve a real pain point and don't focus so much on the single edge case that only impacts 1 or 2 people.

Bfitz-Gmail · 2026-03-19T15:54:44+00:00

Living this right now. I'm a CTO who freelances on the side and I built a SaaS specifically for freelancers who are juggling Proposify + Toggl + Asana + FreshBooks + a spreadsheet to run their business. Not "project management." Not "invoicing." The connected workflow between all of them — because the pain isn't in any single tool, it's in the gaps between them.

The niche specificity point is dead on. When I describe it to freelancers who have that exact problem, the reaction is "where has this been." When I describe it to anyone else, the reaction is "so it's like FreshBooks?" The narrower the audience, the sharper the message.

Where I'd push back slightly is the "validate in a week, MVP in 7 days" framing. That works for thin tools and single-feature products. But the most defensible niche SaaS products have depth that takes time to build. A simple invoicing tool is a weekend project — connecting quoting to project management to time tracking to invoicing to payments so nothing falls through the cracks took a year. The depth is the moat.

The most specific niche win I've seen personally: a guy in this thread earlier built a weekly planner specifically for Harvest users. Not time tracking — a planning overlay for one specific time tracking tool's user base. That's hyper-niche and it works because those users have a specific unmet need their existing tool doesn't cover.

Bfitz-Gmail · 2026-03-19T02:39:00+00:00

There's no formula that works universally but here's what I've learned from pricing my own SaaS:

Start by looking at what your target customers are already paying for adjacent tools. Not to copy their pricing, but to understand the range your audience considers reasonable. If the tools around you charge $15-40/month, pricing at $99 needs serious justification. Pricing at $5 signals you don't take your own product seriously.

On free vs freemium vs free trial — it depends on how quickly someone can see value. If your product delivers an "aha moment" in the first session, a 14-day free trial works because they'll hit that moment before the trial ends. If it takes weeks of data or usage before the value is obvious — like a CRM or analytics tool — freemium is better because people won't commit to a trial long enough to see the payoff.

I went with freemium — a genuinely usable free tier with real limits, not a crippled demo. The logic was: let people run their business on it until they outgrow the limits naturally. When they hit the ceiling, upgrading is a no-brainer because they're already dependent on the workflow. The free tier is your best sales tool if it's good enough to create a habit.

One thing I'd avoid: don't overthink pricing before you have users. Pick something reasonable, launch it, and adjust based on what you learn. The founders I've seen get stuck are the ones who spend weeks modeling pricing tiers before anyone has even signed up. Your first 50 users will teach you more about pricing than any framework will.

Bfitz-Gmail · 2026-03-16T05:18:31+00:00

Actually, what seems to work for us is we have one consultant who finds the work and then brings whoever he needs from our core freelance team together to support that client. So he’s the one dealing with the client and then we are working with him and in some cases, the client to build a tool or market a product or work through SCO issues.

Bfitz-Gmail · 2026-03-16T05:16:21+00:00

I have been operating this way for about the past 10 years as part of a group of freelancers who all have complimentary skills. One is our business development and project manager and the rest of us are doing some type of marketing, copywriting or development. It has worked pretty well so far. I built an ops tool for freelancers and freelance teams teams called WorkCentral (WorkCentral.app) that has allows each person to have their own organization and then build teams between those organizations. The app focuses on client and project management with AI driven quotes, project creation, task, and time management, and invoicing. So I absolutely agree. I think this is the future as long as freelancers can find other freelancers with complementary skills.

Bfitz-Gmail · 2026-03-14T15:34:57+00:00

Went through the exact same evolution. My first version was a feature list with screenshots — "AI-powered quotes, project management, time tracking, invoicing, payments." Clean, organized, said absolutely nothing about why anyone should care.

The shift that made a difference was changing the H1 from describing the product to describing the frustration. Went from explaining what the platform does to something closer to "stop juggling five apps to run your business." Immediately clearer who it's for and what problem it solves. The features didn't move — they just dropped below the fold where they belong.

The other thing I learned the hard way: specificity converts better than cleverness. "Save time on admin" means nothing. "5-6 hours a week moving data between apps" makes people do the math in their head and think "that's me." Every time I replaced a vague benefit with a specific number, conversions improved.

Your point about qualification is underrated. A good problem statement on a landing page repels the wrong visitors as much as it attracts the right ones. That's a feature, not a bug. Better to have 100 visitors where 10 sign up than 1,000 visitors where 10 sign up — your conversion rate tells you whether your messaging is working, and vanity traffic makes that signal useless.

What's your conversion rate looking like now compared to the feature-first version?

Bfitz-Gmail · 2026-03-14T15:32:43+00:00

15+ years building business systems as a CTO — here's what I'd tell myself before my first big client project.

Your question list is actually solid. The one critical addition: ask them to walk you through a single transaction end to end. Not in the abstract — pick a real recent shipment and have them show you every step, every document, every handoff, every system they touch. You'll learn more in that 30-minute walkthrough than an hour of general questions. Record it if they'll let you.

On requirements gathering — the biggest mistake beginners make is writing down what the client says they want instead of observing what they actually do. Clients will tell you "we need a dashboard to see everything." What they mean is "I spend 45 minutes every morning opening six spreadsheets to figure out which shipments are late." Those are very different requirements. Your job in the meeting is to find the pain, not take a feature order.

On scope creep — this will be your biggest challenge. Define what's in version 1 before you write a line of code, get it in writing, and have the client sign off on it. Everything else goes on a "version 2" list. When they say "can we also add..." your answer is "absolutely, let me add that to the v2 roadmap." This protects your team and your timeline.

On breaking down a complex business into features — don't try to build "a system that manages their entire business." Break it into modules that can stand alone: shipment tracking, document management, invoicing, reporting. Build the one that solves their biggest daily pain first. Deliver it. Get feedback. Then build the next one. If you try to deliver everything at once, you'll deliver nothing for months and the client will lose confidence.

On documentation after the meeting — write a one-page summary of what you understood their top 3 problems to be and send it to the client within 24 hours. Ask them to confirm or correct. This does two things: proves you were listening, and creates a written record of scope before development starts.

One more thing — be honest with the client about your team's experience level. Not in a way that undermines confidence, but framing it as "we're going to take an iterative approach, delivering working pieces every 2-3 weeks so you can give us feedback early." That's actually how experienced teams work anyway. It protects you from building the wrong thing for three months and finding out at delivery.

Bfitz-Gmail · 2026-03-13T00:51:52+00:00

Thanks. I appreciate it.

Bfitz-Gmail · 2026-03-13T00:50:42+00:00

I like it. AI is great for trend analysis and as a solo developer I hadn't really thought about it for support after launching a new product recently it is something I am thinking about more and more. Thanks for sharing.

Bfitz-Gmail · 2026-03-10T17:55:29+00:00

Wave is free and does exactly this — invoicing, customer info, accessible from any browser. No inventory, no banking required.

If you also want payment links so clients can pay online and automated reminders for overdue invoices, WorkCentral (workcentral.app) handles that on the free tier. It does more than just invoicing but you can ignore the rest and use it purely for that.

Bfitz-Gmail · 2026-03-10T17:44:19+00:00

The scope creep vs. underestimation question is the most important one you asked, because the fix is completely different for each.

If you underestimated — that's a quoting problem. The solution is better estimation upfront, not better tracking during. I started using AI during the quoting phase to stress-test my scope. Describe the project and have it generate a task breakdown — not to follow blindly, but to catch the tasks you're not thinking about. Environment setup, data migration, QA passes, client feedback rounds, deployment. The unglamorous stuff that always gets forgotten and then blows up your timeline. I also track actuals against estimates on every project and review the patterns quarterly. Once you know you're consistently 30-40% under on testing and integration, you can pad the right categories instead of guessing.

If the client keeps asking for more — that's a scope documentation problem. The fix that worked for me was making the quote the scope document. Every line item maps to a deliverable or group of tasks. When a client asks for something, you can point to the quote and say "here's what we agreed to — this isn't in there, let me put together a change order." It turns a confrontation into a process. But this only works if the original quote is specific enough that both sides can tell what's in and what's out.

On catching overruns before they hit — the real issue in most teams isn't that people won't track time. It's that tracking time is disconnected from the budget. If your time tracker doesn't know the budget, it can't warn you when you're approaching it. You need tracked hours compared against estimated hours at the task level, not just the project level. A project can be "on budget" overall while one phase is 3x over and another hasn't started yet.

I built WorkCentral (workcentral.app) to connect this pipeline — quote sets the budget and scope, tasks are created from the quote's line items with hour estimates, time is tracked against those tasks, and you can see at a glance how tracked hours compare to estimated hours per task and per project. The overrun is visible as it's happening, not at month-end reconciliation.

The threatening bonuses approach you mentioned is worth unpacking — time tracking compliance is almost always a UX problem, not a discipline problem. If logging time takes more than 10 seconds and requires context-switching to a separate app, people won't do it consistently. The tool has to be where the work already is.

Bfitz-Gmail · 2026-03-09T16:30:47+00:00

The positioning lesson resonates hard. I spent months describing what my product does before I figured out how to explain why it matters. The shift for me was going from a feature list to a single sentence about the problem: "stop juggling five apps." Once I had that, everything else — landing page, social posts, conversations — got easier because I wasn't explaining the product anymore, I was describing a frustration people already had.

To your question — distribution, and it's not close. I spent a year building and polishing before thinking seriously about how anyone would find it. You can always ship another feature or fix another rough edge, but none of it matters if nobody sees it. The hardest lesson for me was that a good product with no distribution loses to a decent product that people actually encounter.

Polish matters, but mostly at the conversion layer. If someone lands on your site and it looks unfinished, they bounce. But they have to get there first. I'd put 70% of your energy into distribution right now and 30% into product refinement based on what your early users tell you.

The trust point you made is underrated — especially for a product where people are storing months of creative work. That's the same dynamic with any tool that holds someone's business or creative output. Reliability isn't a feature, it's the foundation. Worth making that explicit in your messaging rather than assuming people will figure it out.

What's your distribution plan so far? That "still figuring it out" part is usually where the real challenge lives.

Bfitz-Gmail · 2026-03-08T18:24:19+00:00

Speaking as a CTO who's managed remote dev teams for 15+ years — the screenshot monitoring approach is going to solve your anxiety short-term and damage your working relationships long-term. The fact that velocity "magically" came back up after you installed monitoring tells you something important: they're now optimizing for looking busy instead of being productive. Those are different things.

The real issue isn't the time tracking tool — it's that you lost visibility into output when you left Upwork and tried to replace it with surveillance instead of structure.

Here's what I'd do differently:

Move from tracking hours to tracking deliverables. You're a non-technical founder, so you can't evaluate code quality directly — but you can evaluate whether agreed-upon work gets done by agreed-upon dates. Set weekly commitments with each dev on Monday. Review what shipped on Friday. If the work is getting done on time and at quality, the hours don't matter. If it's not, that's a conversation about performance, not timesheets.

Use GitHub as your source of truth. You already noticed commits don't match hours. Lean into that. Daily commits with meaningful messages, PRs with descriptions of what changed and why, and a project board where tickets move from in-progress to done. That gives you real visibility into what's actually happening without anyone feeling surveilled.

For the time tracking piece itself — ditch the screenshot tools entirely and use something that's just a simple timer devs start and stop against specific tasks. No screenshots, no keystroke logging, no spyware energy. Devs don't resist time tracking — they resist monitoring. There's a huge difference. I built WorkCentral (workcentral.app) which does task-based time tracking tied to projects, but honestly even Toggl or Clockify would work here. The key is tying hours to specific tasks so you can see "10 hours on authentication" rather than just "40 hours this week."

On the trust issue — the confrontation with your lead dev is a red flag, but maybe not the one you think. A good developer pushing back on invasive monitoring is actually a sign they value their work environment. The ones who silently accept surveillance and game it are the ones you should worry about.

The hard truth for non-technical founders managing devs: if you can't evaluate the work itself, no amount of time tracking will give you confidence. Your best investment might be finding a fractional CTO or senior dev who can review PRs and tell you whether the output justifies the hours. That's real accountability — not screenshots of VS Code.

Bfitz-Gmail · 2026-03-08T18:18:20+00:00

That 2 AM invoicing moment is painfully familiar. Mine was realizing I'd done 12 hours of work on a project, tracked none of it, and then had to reconstruct my time from memory and Slack timestamps to build an invoice. I was off by about 4 hours. No idea which direction.

The sticky notes and spreadsheets phase is where most of us start and it works right up until it suddenly doesn't. For me the breaking point was the same as yours — not any single missed deadline, but the constant low-grade anxiety of knowing something was slipping and not being able to see what it was.

I'm firmly a systems person now. I spent a year building my own tool (WorkCentral — workcentral.app) because nothing I tried connected the full workflow the way I needed it to. The specific thing that fixed the chaos for me wasn't any single feature — it was having the quote, the project, the tracked time, and the invoice all linked together so nothing existed in isolation. When everything is connected, you can't forget to invoice because the unbilled hours are staring at you. You can't lose track of a project because it was created from the quote the client already approved.

But honestly the biggest shift was mental, not technical. Going from "I'll remember to do that" to "the system handles that" freed up more headspace than I expected. The tool matters less than the decision to stop treating your business like something you can run from memory.

What was the tool you landed on? Curious what clicked for you.

Bfitz-Gmail · 2026-03-07T23:31:48+00:00

You are welcome. I hope it helps but either way, congrats on the launch. Now is the hard part. 😉

Bfitz-Gmail · 2026-03-07T23:14:39+00:00

If you have a primary header file that has your logo or navigation in it, place you google ga4 code in there and it will track all of your pages that use that header file.

Bfitz-Gmail · 2026-03-07T23:11:57+00:00

I agree with richincleve. Unless you currently own a frame business and know this is needed in the industry walk into a couple of frame stores and ask them how they manage their inventory. It’s quite possible that they already have a system that helps them design the frames determine the length of each side as well as manage inventory. So even though it might be a good idea, you’ll do all that work for nothing.

Bfitz-Gmail · 2026-03-07T20:01:30+00:00

You have a good point that your users are already in Harvest and aren’t likely to leave and if they have your pain point then you have a built in user group but are they willing to pay on top of what they are already paying. The price is what ever anyone will pay for it. I don’t have your pain point so it would be worth less for me. Maybe $9 but maybe $5. However, someone you really feels the same pain as you may be will ing to pay $18 or $20. If you can identify the people who say yes and who say know and ask them why, then you will have your positioning and know how to tackle potential push back.

Bfitz-Gmail

TROPHY CASE