OpalSwift: Research-Driven Product Design for Israeli Freelance Admin

The Problem

Israeli freelancers are legally required to produce compliant tax invoices and track expenses for accountant filing. The tools available to do this exist, but are narrow (invoicing only, or expenses only), Hebrew-only, and disconnected from the client relationship itself — no CRM, no scheduling, no payment collection. Freelancers who serve English-speaking clients, or simply think in English, are left stitching together multiple point solutions, none of which speak their language or their business's actual shape.

The problem I set out to solve: automate Israeli freelance admin, in English, in an interface simple enough that freelancers stop chasing payments and stop losing hours preparing paperwork for an accountant.

Origin

The idea started from one specific person: a ballet teacher trying to open a private dance studio, drowning in enrollment forms, waivers, monthly billing, and payment follow-up. OpalSwift was originally built to solve her problem specifically — a real, working tool for one real business — before I asked whether the same pattern held elsewhere.

Research

I used a mixed-methods approach: primary qualitative interviews to find real pain points, and secondary market research to validate and prioritize what to build first.

Primary research — generative interviews

I conducted in-depth conversations with 10 freelancers across 10 distinct verticals: a dance teacher and workshop creator (the original client), an art class teacher, a photographer, an artist/scribe working on commission, a writer, a plumber, an app developer, a beautician (services, retail, and custom orders), a designer, and a babysitter. I supplemented this with a couple of questions posted to a broader email group, and drew on my own experience as a freelancer.

Rather than a fixed questionnaire, I used one consistent open-ended prompt, phrased slightly differently each time, and followed each person's lead:

"What are your most annoying and time-consuming tasks as a freelancer that you wish you could automate — so you'd have more time for the part that actually makes you money?"

This surfaced each person's own priorities rather than leading them toward features I'd already assumed. Four responses stood out and directly shaped the product:

"Just getting all those expenses together at the end of the month — it can eat hours of time I'd otherwise be writing."— Writer

"I hate begging for money. If I could just get paid without asking and reminding, it would be so much easier."— Art class teacher

"Photographers are creatives, they're super disorganized. There are so many leads lost just for lack of an organized system."— Photographer

"No one has time or patience to sit there setting up some complex custom system. They just want it to work."— Beautician

The beautician's comment, combined with the photographer conversation, is what led directly to the product's core design decision: pre-configured, vertical-specific "skins" instead of a single configurable tool that every freelancer has to set up themselves.

Secondary research — market sizing and precedent

Alongside the interviews, I used AI-assisted research to pull sourced, real numbers on the size of the Israeli freelance market by vertical, and to benchmark comparable successful apps in other markets (US, UK) per industry. This wasn't used to invent features — it was used to validate which verticals had the largest addressable population and where cross-vertical feature reuse was possible, which directly fed the prioritization framework below.

Synthesis

Across every vertical, four recurring pain points emerged, regardless of industry:

• Turning leads into paying customers
• Retaining and managing existing clients
• Israeli tax and invoicing compliance
• No product connects compliance and client management together — in English

The market-gap insight that ties this together: existing tools split into two failure modes — either narrowly single-purpose (invoicing only, still leaving CRM unsolved) or broadly feature-heavy business tools too complex for a creative freelancer to configure. Cross-referenced with language, this produces a simple 2×2: Hebrew vs. English, single-purpose vs. overly complex. OpalSwift was built to sit in the one empty quadrant — English-friendly, compliance integrated with CRM, and radically simplified.

From Insight to Design

• "Skins": instead of a configurable blank tool, each vertical gets a pre-built, opinionated setup — directly responding to the beautician's "they just want it to work."
• Full parity in Hebrew and English — not a partial toggle — which in turn triggered a legal requirement: Israeli websites must meet accessibility standards, so accessibility became a hard constraint discovered through research, not an afterthought.
• Product philosophy: do exactly what's needed, no more, no less. No feature toggles, no hidden costs, one product for the whole admin workflow.

Prioritization Framework

Feature rollout follows a single global roadmap, not a per-vertical one, decided by three criteria:

• What was needed to actually launch for the first real client — the ballet school — grounding the roadmap in a real, working use case rather than a hypothetical one
• What mattered most across the largest number of verticals ("skins") — building shared core first
• High-leverage features: either verticals with a large freelancer population, or features that flex across multiple verticals with small changes — for example, a "gallery" feature that's payment-gated for photographers and public-facing for artists

Design Research

Landing page and visual design decisions were informed by a separate research thread from the feature-prioritization research: direct input from the photographer interviewee, who as a working creative professional had strong, specific opinions on what a well-designed business tool should look and feel like, combined with a benchmark review of leading products in the space — Bloom.io, HoneyBook, and Light Blue Software — to understand current visual and interaction conventions for creative-business tools in the UK and US markets.

Compliance & Trust Architecture

For a product handling client payments, tax documents, and in several cases minors' data (dance and art class enrollment), compliance was treated as a first-class design constraint from day one, not something added before launch.

• Accessibility: built in from the outset and verified automatically on every deploy via CI/CD, to meet Israeli legal accessibility standards
• Tax computation: outsourced to an external API in full compliance with the Israel Tax Authority, rather than maintained in-house
• Payments: handled through payment gateways, inheriting their security and compliance standards rather than custom-built handling
• Data protection: cascading delete, tombstone architecture, and audit logs applied specifically to student/client data, notifications, communications, and payments
• Payment records are append-only — no edit or delete — for financial audit integrity
• Waiver signing uses a checkbox-based confirmation flow that constitutes a secure electronic signature under Israeli Electronic Signature Law, with HMAC used server-side for tamper-evident integrity verification

Where It Stands

OpalSwift is currently in the production hardening stage of V1. Some features were deliberately left for V2 and V3, based on both the original research and ongoing input from beta testers. It's ready for beta release to a waitlist made up largely of the same freelancers who took part in the original research — closing the loop from interview to shipped product. Real usage data from this beta will be the next input into the roadmap.