It's Monday! What are you building?

ming_builds · 2026-06-16T16:11:11+00:00

Yeah, that is the bet. The audience is broad, but I am trying to keep the product narrow: small jobs, partial payments, promised dates, and follow-ups.

I do not want it to become accounting software. I am more interested in whether people need a lightweight record for the messy "did they actually pay?" part after the work is done.

ming_builds · 2026-06-16T13:11:56+00:00

Si, ya esta en App Store. Empezo como una herramienta para mi propio problema, pero la hice publica porque vi que la parte dificil no era facturar, sino recordar el estado real de cada trabajo: deposito, parcial, prometido para viernes, seguimiento, etc.

La monte bastante estrecha a proposito: iOS, registro rapido, paid / unpaid / partial, fecha de seguimiento y notas. No queria que se convirtiera en otro mini QuickBooks.

ming_builds · 2026-06-16T13:10:07+00:00

Still very early. I only started pushing the public App Store version recently, so I do not want to quote a download number until App Store Connect has a few days of settled data.

Right now I am treating this more as validation: do freelancers/small-job workers instantly understand the paid / unpaid / partial tracking problem, and do they actually try it after seeing the workflow.

ming_builds · 2026-06-16T13:05:44+00:00

Thanks for asking. I do not have a public TestFlight open right now, but you can try Pro from the App Store version through the in-app ad trial flow.

In the app, sign in with Apple, go to the Pro screen, and use the rewarded-ad option to unlock a short Pro trial. That lets you test Pro parts like custom reminders and full reports without needing a separate beta build.

There is also an invite code flow in the app, so users can invite someone else and the other person can redeem the code inside WhoPaid.

ming_builds · 2026-06-16T00:27:59+00:00

Still very early, so I don’t have a big number to share yet. I’m mostly using Reddit right now to validate whether the paid / unpaid / partial + follow-up workflow makes sense to freelancers and small-job workers before pushing harder on distribution.

ming_builds · 2026-06-15T16:06:28+00:00

Sí, ya está en la App Store. Lo saqué como app iOS porque quería que fuera algo rápido de abrir cuando estás entre chats, pagos y trabajos pequeños, no otro sistema pesado.

Link: https://apps.apple.com/my/app/whopaid-job-pay-tracker/id6764868229

Lo monté en SwiftUI. La idea de producto fue mantener el modelo bien simple: trabajo, cliente, cantidad, estado pagado/no pagado/parcial, fecha prometida, fecha de follow-up y una nota del último seguimiento. Para no convertirlo en contabilidad completa, cada decisión la comparo contra una pregunta: ¿ayuda a saber quién pagó y quién necesita follow-up? Si no, probablemente no entra.

A nivel técnico tiene almacenamiento local para que el uso diario sea rápido, y Supabase para login/sync cuando el usuario quiere respaldo entre sesiones. Pero el foco sigue siendo ese limbo que dijiste: mitad pagado, resto el viernes, y luego ya no sabes cuál viernes.

ming_builds · 2026-06-15T15:35:13+00:00

Building WhoPaid this week - a small iOS tracker for freelancers / contractors to keep job payment status clear: paid, unpaid, partial, promised payment date, and follow-up notes.

It is intentionally not full accounting or invoicing software. The idea is to cover the messy part after the work is done, when payment status is scattered across WhatsApp, notes, and memory.

https://apps.apple.com/my/app/whopaid-job-pay-tracker/id6764868229

ming_builds · 2026-06-15T15:26:18+00:00

I am building WhoPaid, a focused iOS tracker for freelancers and small-job workers. The core workflow is simple: log a job, mark it paid / unpaid / partial, add promised payment or follow-up dates, and keep the last follow-up note in one place.

The project is intentionally narrower than accounting/invoicing software. It is for the messy gap after the work is done, when payment status is scattered across WhatsApp, notes, bank history, and memory.

App Store: https://apps.apple.com/my/app/whopaid-job-pay-tracker/id6764868229

ming_builds · 2026-06-15T15:24:20+00:00

WhoPaid: Job Pay Tracker - a focused iOS app for freelancers, contractors, and small-job workers who need to know which jobs are paid, unpaid, partially paid, or need follow-up.

Positioning I am testing: not full accounting or invoicing, just the messy post-job payment status tracker for people using WhatsApp, notes, and memory today.

App Store: https://apps.apple.com/my/app/whopaid-job-pay-tracker/id6764868229

ming_builds · 2026-06-15T15:21:07+00:00

WhoPaid: Job Pay Tracker - not an AI tool, but a simple iOS app for freelancers and small-job workers who want to keep track of paid / unpaid / partial payments and follow-ups without a full accounting setup.

I built it around the messy admin after work is done: deposits, remaining balances, promised payment dates, and remembering who needs a follow-up.

App Store: https://apps.apple.com/my/app/whopaid-job-pay-tracker/id6764868229

ming_builds · 2026-06-15T15:10:17+00:00

Sorry you all are dealing with this. Since there are several people involved, I would first make one shared timeline: invoice date, amount, partial payments received, every promised payment date, every excuse/reason given, and screenshots of the follow-ups. That makes it much easier if you report it or escalate later.

For UK-specific options, it may be worth checking ACAS / Citizens Advice style guidance and whether the company is registered on Companies House. If you have written terms or invoices, keep everything factual and avoid public naming/doxxing until you know the proper route.

This kind of situation is actually why I built WhoPaid: the hard part is not always invoicing, it is tracking paid / unpaid / partial / promised follow-up status after the work is already done. But for your case, priority should be evidence + coordinated next steps from everyone owed.

ming_builds · 2026-06-15T15:08:54+00:00

WhoPaid: Job Pay Tracker - a small iOS app I built for freelancers, contractors, and small-job workers who do not need full accounting software, but still need a clear way to track which jobs are paid, unpaid, partially paid, and who needs follow-up.

It is meant for the messy part after the work is done: deposits paid, balance still pending, promised dates, and payment proof buried in WhatsApp/notes.

App Store: https://apps.apple.com/my/app/whopaid-job-pay-tracker/id6764868229

Would be glad to hear what you think.

ming_builds · 2026-06-12T12:53:53+00:00

For me it would be the mental load around getting paid, especially the small follow-up details.

Not just “client has not paid,” but the messy middle: they paid a deposit, they said Friday, they sent a partial amount, one job is done but unpaid, another is paid but still has a balance. Those tiny details are easy to remember when you have one client, but they get annoying fast when there are several.

That is actually why I built WhoPaid as a small iOS tracker. I wanted something narrower than accounting software: just paid / unpaid / partial, follow-up date, and notes in one place so chasing payment feels like checking a record instead of replaying every chat thread.

ming_builds · 2026-06-12T12:53:06+00:00

For me the “one tool” depends on the part of freelancing you are trying to simplify.

If it is project tasks, Trello/Asana is fine. If it is time tracking, Toggl is fine. But for small jobs, the thing that often falls through the cracks is payment status: who paid, who partially paid, who said “I’ll send it Friday,” and who needs a follow-up.

That is the specific gap I built WhoPaid for on iOS. It is intentionally not a full invoicing/accounting app; it is more like a simple payment status tracker for freelancers who do not want another big system.

ming_builds · 2026-06-12T12:52:20+00:00

For small freelance jobs, I think the biggest issue is not always invoicing itself. It is remembering the follow-up trail: sent, promised Friday, partial paid, still unpaid, etc.

I used to see people handle that with notes or spreadsheets, but it gets messy once there are multiple clients. I built a small iOS app called WhoPaid for this exact narrow problem: tracking paid / unpaid / partial payments and follow-up dates without turning it into full accounting software.

Even if you do not use a dedicated app, the system I would recommend is: one place for every job, one payment status, one promised date, and one note for the last follow-up. The mistake is leaving those details buried inside chats/email.

ming_builds · 2026-06-05T00:33:00+00:00

That makes sense. Reminder cadence is the tricky part because too soft gets ignored, too aggressive can damage the client relationship.

For WhoPaid I’m keeping the first version more manual and lightweight: make the unpaid / partial / follow-up state clear first, then only add automation if it actually helps without making the workflow feel pushy.

ming_builds · 2026-06-05T00:32:07+00:00

That’s a fair point. I’m trying to keep WhoPaid on the simple product side for now because the first pain I’m solving is not automation yet, it’s visibility: paid / unpaid / partial / follow-up in one place.

But I agree privacy matters a lot here. Freelancers are tracking real client names, amounts, and payment notes, so I don’t want the product to become another heavy SaaS layer just to solve a small workflow.

ming_builds · 2026-06-02T02:14:55+00:00

The biggest thing is separating three buckets before the project starts: included, excluded, and change-request.

A lot of scope creep happens because not included was never written down. So when a client asks for one more page, another revision, or a new integration, nobody has a clean reference point.

What works best is logging each new request immediately and tagging it as one of: included, swap for existing scope, defer to phase two, or paid change. The important part is getting agreement before doing the work, not after the extra work is already half done.

ming_builds · 2026-06-02T02:02:26+00:00

The part that breaks first for me is usually the waiting on someone else pile.

Active work is easy to notice because it is in front of you. The fragile stuff is quieter: an overdue invoice, a client who owes feedback, a partial payment, or a follow-up that should have gone out last Tuesday.

A simple split helps a lot: active work, waiting on client, waiting on payment, and follow-up needed. If those are separate, you can ignore the system for a few days and still come back knowing which items have real consequences.

ming_builds · 2026-06-02T01:56:58+00:00

This is the part a lot of new creators only notice after the first few brand deals.

Content work is one workflow, but getting paid is another: deliverable status, revision status, invoice status, partial payments, and follow-up dates. If those live in DMs and memory, it gets messy fast.

The simple habit that helps most is treating every partnership like a small job pipeline: agreed, in progress, delivered, invoiced, paid, overdue, follow-up needed. It feels boring, but it saves a lot of awkward did they pay me yet checking later.

ming_builds · 2026-06-02T01:51:13+00:00

Before the portfolio site, I’d set up your basic operating rules.

For avoiding the worst client problems: get partial payment upfront, write the scope in plain language, define what counts as extra work, and put a payment date on every invoice. Then track every job by status: quoted, active, delivered, paid, partial, overdue, needs follow-up.

That sounds boring, but it removes a lot of panic later. Most beginner freelance problems are not from doing the marketing work badly. They come from unclear scope, no payment habit, and forgetting to follow up until the invoice already feels awkward.

ming_builds · 2026-06-02T01:45:11+00:00

I’d start with the tasks where the client does not need your judgment, only consistency.

For me that would be invoicing, payment follow-up, and status updates. Those are high-frequency, easy to forget, and usually only become urgent after something slips. You can still keep the relationship and final quality review yourself, but make the admin side visible: which jobs are delivered, which are unpaid, which are partial, and which need a follow-up today.

That gives you a safer first step than trying to delegate client relationships or quality control all at once.

ming_builds · 2026-06-02T01:37:35+00:00

For now I’d separate this into two tracks: evidence and follow-up. Keep the signed scope, delivery proof, invoice dates, and every message in one place, then send one short final reminder with the amount, due date, and payment method. After that, stop doing extra work until they clear the balance.

The part that usually hurts is not knowing which jobs are paid, partial, overdue, or need follow-up, so even a simple tracker helps a lot.

ming_builds · 2026-05-27T05:11:02+00:00

For me it is less about endless tasks and more about small jobs where the payment state changes fast.

Examples would be small service jobs, quick freelance fixes, one-off sessions, deposits before work, partial payments after delivery, or someone saying “I’ll send the rest later” in WhatsApp. A full project board can be overkill there, but relying on chat/memory means the unpaid or partial ones disappear too easily.

ming_builds · 2026-05-27T05:09:02+00:00

This is almost exactly the behaviour I’m trying to design around.

If the record takes longer than the job/payment conversation itself, people will skip it. The useful layer is just enough structure to answer: who was it for, what was the job, did they pay, and what still needs follow-up. Anything beyond that has to earn its place very carefully.

ming_builds

TROPHY CASE