Asansoft

Context

Asansoft is a B2B SaaS for elevator maintenance firms in Türkiye. Three clients — iOS, Android, web — speak to a single backend. I've been field-testing it in the Marmara region through 2025, ahead of a public launch in 2026. No paying customers yet: the system is built and works, and I'm hardening it against real-world use before I sell it.

I built the whole thing solo: product, design, three platforms, backend, deployments. No technical co-founder, no investment. I registered a Turkish şahıs şirketi at the end of 2025 so I can bill customers cleanly at launch.

The product does three things: a technician logs an inspection from a no-signal basement; the firm owner sees what's been serviced today without phoning anyone; and the system generates TS EN 13015-compliant signed, photographed PDF reports for the archive.

Problem

Picture the field: a maintenance technician is in the boiler room of a 1990s apartment building in Bursa. There's no 4G. They've already serviced four elevators this morning. They have to fill out a paper form for each, get the building manager to sign it, and somehow get all of that into the office system before payroll on Friday.

The reality of the sector before software:

• Forms live on paper. The technician's car has a stack of triplicates.
• Invoices go out a week late because the office has to chase the technician for what they did.
• The firm owner doesn't know what was serviced today — they call the technician.
• The legal regulation (TS EN 13015) requires every inspection to carry a signature and a photograph in the archive. Paper forms barely meet this; getting an audit-ready record is painful.
• Customer disputes ("you didn't service my building last month") are settled with paper trails or memory. Both lose.

The pitch I made to firms: stop carrying paper. Your technician fills the form on a phone — works offline, syncs when signal comes back. You see everything from the office. The PDF for the archive is automatic.

Constraints

• Offline-first is mandatory. No signal in basements is the default, not the edge case.
• KVKK compliance. Personal data must stay in EU/Türkiye-bridge regions.
• Customer budget is small. SMB elevator firms can't pay enterprise SaaS prices. Subscription has to land below ~₺1,000/month per firm.
• Three platforms simultaneously. iOS for iPhone-using technicians, Android for the rest, web for the operator. Skipping any of them kills adoption.
• Solo developer. I build, I deploy, I take the support call. Anything that doubles maintenance is rejected by default.
• Field UX matters more than visual polish. Gloves, basement lighting, fast data entry. The form is the product.

Approach

The four decisions that shaped everything:

Backend — single PostgreSQL with row-level security

A single PostgreSQL instance serves all three clients. Multi-tenancy is enforced by Postgres RLS policies keyed off organization_id — every query carries it implicitly via the JWT. Microservices were never on the table: the operational overhead would have eaten the subscription budget, and one developer can't sensibly run a distributed system.

I added BullMQ on Redis for background work — sync conflict resolution, PDF generation, scheduled report sends. The queue runs in the same process as the API; not glamorous, but it lets me reason about the entire system in one trace.

Mobile — React Native + Expo

Writing native iOS and native Android in parallel was never realistic. React Native + Expo gets me about 85% code share. The remaining 15% is native modules — Bluetooth printers for receipt printing, accelerometer access for one diagnostic flow, photo compression worker. Trade-off: certain interactions feel a frame slower than full native; the engineering customer doesn't notice, the technician doesn't care.

Offline-first — WatermelonDB

I considered SQLite with hand-rolled sync first. The cost-of-correctness on hand-rolled sync was higher than I wanted to pay, especially for "what if the technician's phone restarts mid-inspection" cases. WatermelonDB gives me an observable, indexed local store that sync-batches changes when network appears. Trade-off: schema migration is the part I least look forward to. Six months in, this is still the friction point.

Auth + hosting — Supabase + Vercel

Writing my own auth on top of a B2B billing system in 2025 is a self-inflicted wound. Supabase gives me email/password, magic link, and RLS-aware JWTs out of the box. Region: EU, which gives me a Türkiye-acceptable data residency story. Web operator panel runs on Vercel; the whole stack runs comfortably under a $30/month budget at pilot scale.

Code: sync conflict resolution

The pattern that keeps two technicians from accidentally overwriting each other's record:

type Record = { id: string; updatedAt: number; revision: number; payload: Json };
 
async function resolveConflict(local: Record, remote: Record) {
  if (local.revision === remote.revision) {
    // No conflict — same base. Apply local on top.
    return { winner: "local", diff: null };
  }
  if (local.updatedAt > remote.updatedAt) {
    // Local is newer; client keeps it, server gets a diff to merge.
    return { winner: "local", diff: computeDiff(remote.payload, local.payload) };
  }
  // Remote wins; client must rebase its pending change on top.
  return { winner: "remote", diff: computeDiff(local.payload, remote.payload) };
}

The current build is last-write-wins with revision counters. The v2 I'm building moves the merge into the operator panel — the firm owner sees a small "two technicians edited this" badge and a one-click rebase.

Trade-offs (what I didn't build)

No microservices. A single Postgres + Vercel function pool serves the entire product. The cost of distributed-systems complexity at this scale is paid in operations, not features.

No native iOS / Android. React Native carries 85% of the code, native modules carry the rest. The 15% UX gap a fully-native app would close is invisible to the buyer.

No custom design system. Tailwind + a small layer of conventions. I shipped the entire admin panel in two weekends because of this. The cost: the app is recognisably "shadcn-flavoured" if you know what you're looking at.

No real-time WebSockets. Inspection records aren't real-time. Operators don't refresh more than once every few minutes. Polling every 30s covers it, and it's far less to build and maintain than a Realtime-channel design.

No external investment. I'm building it on my own time and freelance income — no runway clock. The trade I made: I'm slower than a funded team would be. The trade I kept: it answers to whether it's genuinely useful, not to a fundraising timeline.

What works so far

• Field form completion time dropped from ~12 minutes (paper) to ~3 minutes (mobile) in my own field tests.
• PDF reports for the TS EN 13015 archive generate signed + photographed records in under 2 seconds on the operator panel.
• Three platforms built from one codebase — iOS, Android, web.
• Operational footprint stays under $30/month all-in at current pre-launch scale (Vercel + Supabase + Redis).
• Offline sync holds in the field — I've run it in real basements, no signal, real devices, and it recovers cleanly.

Hard customer-side metrics — firm counts, monthly volume, crash rates, uptime — come after there are real customers to measure, post-2026-launch. I'm not going to publish numbers before they exist.

Now and what I learned

What I'm working on right now is the v2 sync UX I mentioned above — moving from last-write-wins to optimistic concurrency with a merge UI. The hard part isn't the algorithm; it's the operator panel surfacing the merge in a way a non-technical firm owner can resolve in three seconds.

Three lessons that stuck:

1. Speak the customer's language. "Bakım kaydı" is not "inspection record." Domain language is product language; using the customer's words in the UI builds more trust than any landing page.
2. Solo founders should keep the product small. Every feature is 2x cost — build it, then maintain it. The features I'm proudest of are the ones I cut from the roadmap.
3. KVKK is an advantage, not a tax. "Your data stays in Türkiye" is a stronger trust signal in this segment than any feature comparison.

If you're building something like this — offline-first mobile, multi-tenant Postgres, B2B SaaS in Türkiye — email me: hello@metehanugus.com.