Selected work
The builds, and what was hard about each
Each case study covers the problem, the constraints, what we built, and one specific thing that went wrong along the way. The last part is the one worth reading.
A brokerage running on board software, a Word document and an inbox.
A mortgage brokerage tracked live deals on a board tool, sent its application form as a Word document by email, and collected client paperwork as attachments. We replaced all three with one portal: a six-step client journey, an application form inside it, and a document vault the broker can actually search.
The switch that had to be off before it existed
Four campuses, one database, isolation that had to be provably real.
A network of campus organisations ran on a 135,000-line WordPress plugin. One install per campus, student records duplicated across sites, no shared reporting, and a Salesforce org nobody trusted. We replaced it with a single multi-tenant platform.
Row-level security that silently did nothing
A $1.58M interest-free loan fund whose headline number was wrong by $47,383.
An interest-free community loan fund ran on spreadsheets, contracts in Google Drive, and a bookkeeping tool with no transaction export. We built the ledger, and in the process found that the number everyone quoted was measuring the wrong side of the balance sheet.
The headline number was measuring the wrong side
A rewrite shipped to an installed base, without reaching zero users.
Shipping a rewrite to an installed base without dropping anyone. A daily-habit app moved from a progressive web app to React Native in both stores. The rewrite was the easy half. The hard half was delivering updates to people who already had the old build on their phone.
The update that publishes successfully to nobody
Billable hours were leaking. The API could not answer the question being asked.
A managed service provider could not tell whether its engineers were logging time. We built a near-real-time compliance portal on top of a PSA API that times out on any query broad enough to be useful.
Designing around an API that cannot answer the question
The booking calendar rendered perfectly, and it was empty.
A therapeutic horse-riding practice took bookings by phone and WhatsApp. We built a bilingual Hebrew/English booking site with a self-service admin, then hit a failure mode that produces no error at all.
A failure mode with no error state
Everything else we've built 11 more projects
Multi-tenant platforms
- Campus site builderDrag-and-drop public sites, multi-tenant
- Client project portalMilestones, tickets and plan approval: this site runs it
Business systems & integrations
- PredictableStock curation & analysis, live broker integration
- Same-day delivery networkMulti-carrier rate-shop injected into checkout
- Warehouse operations assistantNatural-language interface over 3PL operations
Consumer & mobile apps
- DavenenApp StorePrayer-partner matching platform
- KartovShared lists & meal planning
- Temani ChachamApp StoreYemenite siddur with a rule-driven prayer engine
- TapSendBulk messaging with a manual send gate
- Investment firm siteMarketing site and content platform
- Advocacy campaign platformHebrew-first campaign site with media pipeline
Client work is described by shape rather than by name. We don't put client brands, logos or data in our marketing, including in screenshots.
Want the same treatment on your problem?
The first conversation is us working out whether this is a build, a fix, or something you should not do at all.