What I'm not building. And what I might be.

People email me with feature requests. Most of them fall into two buckets, and I find myself answering them differently.

First bucket: things I'm not going to build. Ever. Either the existing tools are already great, or the feature would make AllMy worse for the people it's actually for. Either way I'd just be a worse copy of something else, and I don't want to be a worse copy.

Second bucket: things I haven't built yet, but might. These I'm honest about. I see why you want them. Here's why they aren't in v1. Here's what would have to be true for me to build them.

The gap between the two buckets is most of what differentiates AllMy from QuickBooks. So it's worth saying out loud.

The genuine no's

Payroll

People want this. I keep saying no.

The reason isn't that payroll is too hard. It's that payroll is a regulated, multi-state, constantly-changing problem already solved by Gusto, Patriot, Rippling, and yes, Intuit's own QBO Payroll. Those teams employ payroll specialists in every state. They watch the legislation. When California changes a withholding table at midnight, they're awake.

AllMy can't compete on that, and I'm not going to half-build it. What I'd ship in three months would be a worse Gusto, and Gusto is $40 a month. The math doesn't work for anyone.

The right answer for AllMy users with employees: pair it with a real payroll service, then either import the journal entries each month or post a single summary entry. That's a five-minute task once a month. I'm not going to charge you twice for it.

AI auto-categorization

AI categorization is the thing every accounting product is racing to ship right now. I'm a developer who builds with these tools every day. I'm not going to ship this for your tax return.

What "AI categorization" actually does, today, is pattern-match against your past behavior. If you miscategorized something six months ago, the model learns your mistake and confidently makes it again. There's no audit log of why a decision was made, no rollback that doesn't break six other things, and no liability when it's wrong. That liability is on you, on tax day.

Rule-based suggestions are different. "Last time you bought from this vendor, you put it in Office Supplies; want to do that again?" That's a five-second prompt with a clear answer. AllMy can do that. What I won't do is hide the decision behind a black box and tell you to trust the model.

Maybe in five years. Right now: you're better off categorizing your own books, slowly, with a hot drink. (I wrote a longer version of why I think this way when I first built AllMy.)

Inventory management

If your business tracks SKUs, cost layers, and stock counts, you want a different product. Not a worse one. A different one.

AllMy is for service businesses, freelancers, and small businesses that occasionally invoice for a part or a small amount of physical goods. The chart of accounts has the entries you need to track inventory at a high level (cost of goods, sales, an inventory asset account), but it doesn't track SKUs, doesn't manage warehouses, doesn't reorder.

For real inventory management, look at Sortly, Zoho Inventory, or Cin7. Or, if you're at the scale where this matters, an actual ERP. AllMy can sit downstream of any of them.

The not yets

Those three are settled. The next four aren't. They're things I haven't built but might, and I owe you actual reasoning rather than a roadmap with dates.

Bank aggregators (Plaid, Yodlee)

AllMy currently imports transactions from your bank via OFX or QFX file. You log into your bank, click the export button, save the file, drop it into AllMy. It's old-fashioned but it works, and your bank credentials never leave your computer.

The modern way is to hand your bank login to a third-party aggregator (Plaid, Yodlee, MX) that logs in on your behalf and streams transactions back. It's more convenient. It also costs around $0.50 per account per month at scale, which is fine for a $40-a-month subscription business and a problem for a one-time purchase.

I'm not opposed to it. If there's enough demand, the most likely shape is an optional add-on for users who want bank feeds, separately priced, opt-in only. I'd rather charge the people who want it than spread the cost across people who don't.

A mobile companion

There isn't going to be a full AllMy Ledger app for iPhone or Android. Bookkeeping wants a keyboard.

What's plausible is a small companion app: snap a photo of a receipt, type the amount, pick a category, and have it sync to the desktop file when you next open the laptop. That's a different scope than "mobile bookkeeping." It's also a different architecture, because it involves a sync service or a cloud-relay step, which means it has to coexist with the local-first promise.

I haven't designed it yet. If I build it, I'll write about it before I ship it.

Accountant review and multi-user

AllMy is single-user today. One person, one file, one computer.

Two requests come up regularly. The first is "I want to give my accountant read-only access to last quarter so they can review my books before tax time." The second is "My partner does invoices and I do reconciliation, can we both work on the same file?"

Both are fair asks. They're also different problems.

Read-only accountant access is closer. It probably looks like an export-and-share flow rather than a real-time sync: you generate a snapshot, you share a link or a file with your CPA, they review it. That's tractable.

Genuine multi-user editing of the same file from two computers is harder. SQLite isn't designed for it, the conflict-resolution problem is real, and I'd rather do it once and right than ship a hack that bites someone in the middle of a reconciliation.

I think about both. Neither is on a near-term roadmap.

Online payment links in invoices

Email invoicing shipped a few months ago. The natural next step is a Pay Now button on the invoice that takes the customer to a Stripe-hosted checkout. I get this request often.

It's the most likely of the four to ship. The integration is a Stripe Connect account, a webhook that records the payment back to AllMy, and a small UI for the customer. None of that is exotic.

The question is who eats the processing fee. Stripe takes 2.9% plus 30 cents per transaction. On a $5,000 invoice, that's $145.30 the customer pays you, then you pay Stripe. The customer doesn't see that. You do, every time. I want the option to be there but I don't want to surprise anyone.

This will probably ship before any of the other three above.

How I decide

I'm not going to give you a roadmap with dates. Dates make people angry on a schedule.

What I will tell you is what I think about when someone asks me to build something.

Does it fit a one-time-purchase model, or does it require recurring revenue to sustain? Bank feeds and online payments both have ongoing costs that have to come from somewhere.

Does it require a backend service that breaks the local-first promise? Mobile sync and multi-user both do, in different shapes.

Does it make the simple case harder for users who don't need it? AI categorization absolutely does. Most of the rest don't.

Is there an existing tool that already does it well, that I'd just be a worse copy of? Payroll, inventory, full mobile bookkeeping. Yes, yes, yes.

If most of those answers come back red, I don't build it. If they come back green, the question becomes when, not whether.

You're welcome to tell me which feature you want me to think harder about. I read the email.

If any of this resonates, and especially if you'd been waiting for one of the not-yet features above, the rest of AllMy Ledger is at allmy.software/ledger. There's a free 7-day trial.