Hi, I'm
franki.

Aerivo: VFR Flight Planning & Digital Logbook

Full-stack SaaS for general aviation pilots that brings flight planning and complete pre-flight preparation into one place.

The problem

General aviation pilots across Europe were stuck juggling separate tools for flight planning, weight & balance calculations, and logbook tracking, none of them built for how pilots actually fly. Existing logbook software felt like it was designed for commercial airlines, not someone flying a Cessna out of a grass strip on weekends.

What we solved

• Weight & balance across aircraft types. Every aircraft has different empty weight, fuel capacity, and center-of-gravity envelopes. We built a system that pulls the right reference values per aircraft and validates the calculation live, catching out-of-range loading before a pilot ever gets to the runway.
• Real weather parsing. METAR reports are dense, abbreviated aviation weather codes. Early versions of the parser choked on edge cases, non-standard station formats, missing fields, unusual wind notations. We rebuilt the parsing logic to handle these gracefully instead of silently failing, since a pilot trusting bad weather data is a real safety issue, not just a bug.
• Cross-country time logic. Aviation logbooks track cross-country time differently from total flight time, with specific distance and landing requirements. Getting this calculation wrong doesn't just look bad, it can affect a pilot's certification records. We rebuilt the logic against the actual regulatory definitions instead of approximating it.
• Reliable exports. Pilots need their logbook data portable, for insurance, certification renewals, or switching tools. We rebuilt PDF export to handle larger logbooks and edge-case entries without breaking formatting.

Live: https://aerivo.net/

Marcowy Zając

Pre-login landing page for a Warsaw catering company delivering meals to nurseries, preschools and schools.

The pre-login landing page for a Warsaw catering company that delivers meals to nurseries, preschools and schools. Institutions place their orders online in about two minutes, with no phone calls or emails, and get punctual delivery every working day. The page is built to communicate trust and make the whole ordering flow feel effortless.

Live: https://marcowyzajac.pl

Marcowy Zając: Ordering & Operations System

Full-stack platform for a catering company serving thousands of meals a day.

The problem

A Warsaw catering company delivering meals to nurseries, preschools, and schools was running everything through phone calls and manual coordination, facilities calling in orders, kitchen staff working off printed sheets, drivers reporting deliveries verbally, and month-end invoicing done by hand across every location.

What we solved

• Order chaos across dozens of facilities. Every facility ordering by phone meant errors, missed changes, and no record of what was actually requested. We built an online ordering flow facilities complete in about two minutes, no calls, no back and forth, with every order flowing straight into a dashboard the kitchen actually uses on shift.
• Kitchen visibility. Kitchen staff had no way to see order volume ahead of time, they found out what to cook as calls came in. We built a live tablet view showing breakfast, lunch, and afternoon snack portions ready versus needed, with instant notifications plus an email backup whenever a facility changes an order.
• Delivery status blind spots. Admin had no way to confirm deliveries without calling drivers directly. We gave each driver their own login to mark off completed deliveries, so delivery status is always visible without a single phone call.
• Manual invoicing at scale. Reconciling servings per facility by hand took days every month. Every order now automatically rolls into billing, with total servings counted per facility and integrated with KSeF, cutting month-end invoicing from days to minutes.
• Data protection across roles. With kitchen staff, drivers, facility admins, and company owners all using the same system, access needed hard boundaries, not just hidden UI elements. We enforced role-based access at the database level, so each role only ever sees what it's scoped to see, and every query is parameterized against SQL injection.

Live: https://panel.marcowyzajac.com/

Issiofy: Invoicing Platform

A compliant invoicing engine built on commission for a French company.

The problem

A French company needed an invoicing system that could keep pace with actual business complexity, partial payments, credit notes, quotes that convert into invoices, deposit invoices, all while staying legally compliant with France's e-invoicing requirements. Off-the-shelf tools either handled the basics and broke under real edge cases, or came with far more overhead than the business needed.

What we solved

• Gapless, legally valid invoice numbering. French accounting law requires sequential, unbroken invoice numbers per company, with no gaps and no duplicates, even under concurrent approvals. We built approval logic using ordered row-level locking across invoice and counter tables inside a single transaction, tested under simultaneous approval load to guarantee no duplicate or skipped numbers.
• Immutable approved invoices. Once a French invoice is approved, it legally cannot change. We enforced this at the database level with triggers blocking any update or delete on approved or sent invoices, rather than relying on application code that a future change could accidentally bypass.
• Credit notes that can't over-refund. A credit note issued against an invoice needs to correctly account for every prior credit note against that same invoice, inside the same locked transaction, or double-refunds become possible under concurrent requests. We built and tested this against exactly that race condition.
• Documents that read data differently depending on legal status. Quotes are not frozen legal documents in France, so they read live company and pricing data. Approved invoices are frozen the moment they're approved, capturing a snapshot of seller and buyer details at that exact point. Getting this distinction right meant building two different data-reading strategies into the same system depending on document type.
• Real payment and reminder infrastructure. We built automatic overdue detection with deduplicated reminders, payment-status tracking that only ever moves forward, never regressing a paid invoice back to a prior state even under network delays or concurrent webhook events, and made invoice state transitions atomic instead of trusting application-level checks against potentially stale data.