How I Build Software That Fits Around Your Business — Not the Other Way Around

Walk into any small or mid-size business that commissioned custom software in the last few years and you'll see the same pattern. They signed off on a 50-page spec. Paid a third up front. Waited four months. Ended up with a system nobody wants to open, because it was built around a flowchart — not around the day-to-day of the people who actually use it.

I work differently. Here's what it looks like — and why the clients who go through this process with me don't go back.

Why most "custom software" projects disappoint

Custom software for a small business doesn't fail because the developers aren't good enough. It fails because it starts in the wrong place: a written spec. A spec captures how one executive imagines the business in a vacuum. It doesn't capture how the driver loads a truck, how the office clerk enters an order, how the warehouse manager keeps a parallel Excel because the system never quite matched reality.

Field staff don't read specs. They open the app, try to do their job in it, and if it fights them — they go back to Excel and WhatsApp.

Four failure patterns I see again and again:

• All-or-nothing launch. Six months of silence, then 80 screens drop at once. Half don't match how anyone actually works. The team quietly ignores them.
• Translation bolted on at the end. Built in English, translated to Hebrew (or any non-English market language) at the last minute. Forms mirror wrong, dates are in the wrong format, every sentence is addressed to a male user only.
• Wrong device, wrong context. Buttons sized for a developer at a desk get used by a field worker with gloves and direct sunlight on the screen.
• No real ownership. Code on the agency's server, hosting on their account, every change a fresh quote. The lock-in is the business model.

The common thread: nobody designed the system around where the work actually happens.

How I actually work — six phases

1. I show up in person, not over a spec

The first thing I do is come to the business. Two or three hours on site. Not just with the founder — with the clerk entering orders, the driver loading the truck, the warehouse manager maintaining the side-Excel. I ask what annoys them every day. I watch where they enter the same data twice, where they keep paper notes stuck to the monitor, where they call each other to verify something the system should already be showing.

This is the real difference. A spec describes what the buyer thinks the business needs. A site visit shows where the friction actually lives.

2. Something useful ships in weeks, not months

Within two to four weeks of kickoff, a working slice exists. Not the whole system. Not 80 screens. One or two features that replace a painful manual process — a stock check, an order intake, a digital signature instead of a paper one. The team is already using it by week three. Things that don't work, we fix. Things we didn't think of, we add in the next cycle.

You see the system running long before the 50% milestone. That changes the entire dynamic. You're not paying against a promise. You're paying against something already operating in your business.

3. Hebrew (or your market language) from the database out

I don't translate. I build the system in the target language from the data model up — field names, addressing conventions, date formats, reading direction. RTL on day one, not a CSS skin glued on at the end. Status labels match the way the team talks about them in the office, not what a developer imagined from a glossary.

A client told me once: "This is the first system that talks to me in actual Hebrew, not translator-Hebrew." That doesn't come from an auto-translate pass. It comes from sitting with the people who use the system and writing the screens in their voice.

4. The rules can't lie — they're enforced where they matter

If you can't book the same truck for two overlapping dates, that's not a check in the UI — that's a database constraint. If only a manager can authorize a 15% discount, it isn't just a greyed-out button — it's a server-side rule. If a stock movement is signed off, it can never be deleted, only paired with a correction record.

That sounds technical, but it's the difference between a system you trust and a system you re-verify in Excel every evening. When the rules live in the data layer, the UI matters less. The data can't be broken — not by accident, not on purpose.

5. Interface tuned to where each person actually works

The office staff member sits at a 27-inch monitor and sees a horizontal two-week calendar of every booking. A field worker in the same business opens the app on a phone, on patchy cell signal, with the sun in their eyes, and sees only the two pickups they need to handle today. Same data underneath, totally different surface — because they're doing two different jobs.

Systems that ignore that distinction — that show the same dashboard to everyone — force field staff to scroll eight times to confirm a delivery. So they call the office instead. So the system stops mattering.

6. You own the code

I work on open, standard infrastructure — Supabase, PostgreSQL, GitHub. The accounts are in your name. The code is documented. If in three years you decide to work with a different developer, they can pick it up without drama. No monthly license that doubles after year one. No lock-in forcing you back to me for every small change.

Which means I have to earn each return engagement on the work itself. Seems fair, and it also keeps me honest.

The kinds of projects I take on

• Internal operations systems — inventory, rentals, scheduling, customer management, digital signatures.
• Mobile apps for field teams — drivers, technicians, maintenance staff, service crews.
• Integrations between tools that don't talk — invoicing platforms, Google Calendar, WhatsApp Business, CRM systems, payment processors.
• Marketing sites with an internal area — admin dashboards, private client portals, booking systems, manager panels.
• Modernizing a legacy system — when the existing platform is no longer maintainable, but the data inside it is critical to keep.

When this isn't the right fit

I'd be lying if I said this works for everyone:

• You need a system serving 200 active users from day one. That's a team project, not a solo-developer project.
• There's a 90%-fit off-the-shelf tool already. Sometimes Monday, QuickBooks, or Shopify is genuinely the right call. I'll tell you that in the first call, not after I've quoted you.
• You want to "order it and forget about it." The two hours on site at the start aren't optional. Without your involvement during discovery, the result won't be sharp enough.

How to start

A 30-minute intro call by phone — free, no commitment. If it sounds like a fit, I come to you for a two-to-three-hour site visit to see the work in person. After that you get a clear proposal: scope, milestones, fixed price. No open-ended hours, no surprise line items.

If you'd like to see what this looks like in practice, you can read a deeper case study of one recent project, look at another one running in production, or scroll down and message me directly. I read and reply personally.