I turn problems into working products.

The problem

Notary signing work is coordinated across email threads, text messages and spreadsheets. Orders get assigned by hand, providers are chased for availability, documents scatter, and nobody has a reliable view of what is in progress or what has been paid.

What I learned

The scheduling was never the hard part. The hard part was everything attached to it: who is allowed to see which order, how a quote becomes a job, when a provider gets paid, and what happens when a date changes. The real product was the operating system around the calendar.

What I decided to build

A single platform covering orders, clients, providers, quotes, documents, invoicing and payment status, with permissions strict enough that enterprise clients and independent providers can work in the same system without seeing each other's data.

How I built it

React and TypeScript on Supabase and Postgres, with row-level security driving every permission decision, Stripe for payments, and integrations that let partner systems create and track orders through an API.

What happened

Usage from an active customer over a three-month period.

The problem

I hit this one from the inside. As an officer of my own Rotary club, I watched member records live in one spreadsheet, attendance in another, the website somewhere else entirely, and every newsletter get rebuilt from scratch. Volunteer-run organizations lose hours to work no one signed up for.

What I learned

These organizations do not need more software. They need one place where the member list is the source of truth and everything else reads from it, because the people maintaining it change every year and nothing complicated survives a handover.

What I decided to build

A platform covering the public website, membership applications, the member directory, events, attendance, communications, newsletters and document storage, with permissions granular enough that a president, a secretary and a committee chair each see only what they need.

How I built it

Multi-tenant from the ground up so each club gets its own site, branding and custom domain on shared infrastructure. React and TypeScript on Supabase and Postgres, with a permission model built around page-level access keys and self-serve onboarding from purchase to live site.

What happened

Running live with the Rotary Club of Charlottesville, with self-serve onboarding open for additional clubs.

The problem

Small service businesses know online reviews decide whether they get found, but asking for them is manual work that gets skipped. The ask either never happens or arrives days late, when the customer has moved on.

What I learned

Timing and personalization matter more than volume. A request that arrives shortly after the job, referencing the actual work, performs very differently from a generic blast. That meant the product had to know when a job finished, which is a data problem, not a marketing one.

What I decided to build

A workflow that triggers on job completion and runs itself: wait, send a personalized request, follow up once if there is no response, then stop. Built as a standalone product so any business can use it, not as a feature buried inside another platform.

How I built it

A generic business, customer, service and review-request data model so the workflow is not tied to one industry, a direct integration with OpenSked, and a public API so other platforms can trigger the same workflow from their own systems.

What happened

1. Job completed
2. Wait
3. Personalized request
4. Follow-up
5. Review

Running against real customer jobs, with the API available to businesses outside the OpenSked ecosystem.

The problem

Small businesses get quoted a large one-time fee for a website, then get left with something they cannot update. A year later the site is stale and the owner is back where they started.

What I learned

The obstacle is not cost, it is ownership. Owners do not want a content management system to learn. They want the site to stay current without becoming another job on their list.

What I decided to build

A subscription instead of a project. Website creation, hosting, ongoing updates and digital support bundled into one recurring price, with a US-market counterpart under a separate brand.

How I built it

Shared multi-tenant infrastructure so one codebase serves every customer site, with per-customer theming, domains and content, built to make routine updates fast enough to include in a subscription.

What happened

Operating in the Bulgarian market with a US-market equivalent built on the same platform.