What we can do,
and have done

Everything below is evidenced by KRIDAXA, which is live and handling real bookings and real money. If something is not on this list, we have probably not shipped it, and we will say so.

Platform engineering

Two-sided marketplaces end to end: listings and search, the booking path, roles and permissions, and the operator console that keeps it running.

The hard part of a marketplace is never the catalogue. It is what happens when supply is contended, when a booking has to be undone, and when two parties disagree about what was agreed.

Web and mobile

An Angular web application covering several role-gated surfaces, and a Flutter app shipping to both iOS and Android from one codebase.

Both talk to the same API. That is a deliberate constraint: the moment a mobile app gets its own copy of a pricing rule, the two answers start to diverge and nobody can say which is right.

Cloud and infrastructure

AWS hosting, environment separation, versioned database migrations, release versioning and the deployment process around them.

Every schema change is a numbered, reviewed script rather than something applied by hand to a production database and remembered differently by two people.

Payments and invoicing

Collection through authorised payment gateways, GST-compliant invoice numbering, commission splits, refunds, and payouts that reconcile.

Invoice numbers are a regulated sequence. Spending one on a document that evidences no supply is the sort of mistake that is cheap to make and expensive to explain, so the rules live in code.

Reporting and reconciliation

Utilisation, earnings, payout statements and settlement trails — the figures an operator is actually accountable for.

A dashboard that cannot be tied back to the individual bookings behind it is decoration. Ours traces end to end.

Scheduling and capacity

Slot availability under contention, recurring series, group seats that release individually, waitlists, reschedules and cancellation policies.

This is where most booking products quietly break. Showing a calendar is easy; being correct when two people tap the same slot at the same moment is not.

Where we are heading

AI, on top of a system that already reconciles

Not shipped yet, and we will not pretend otherwise. Here is the honest position, because it is more useful than a page of AI buzzwords.

Why we think we are well placed for it

Most AI features on operational software fail for an unglamorous reason: the underlying data cannot answer the question. If your bookings, refunds and payouts do not reconcile, a model asked "why is this payout short?" will produce a confident sentence with nothing behind it.

KRIDAXA already has the part that is hard to retrofit — a settlement trail where every figure can be traced to the bookings that produced it. That is the substrate a useful assistant needs, and it is the reason we built it before reaching for a model.

What we would build first

Narrow, high-stakes, low-volume work where a human still decides. Explaining a settlement figure against the rules behind it. Drafting a support reply grounded in that customer's actual booking and refund state. Cross-checking submitted KYC documents against each other.

Not a chat bubble bolted onto a dashboard, and not a product recommendation engine. Those are the easy demos and the weak outcomes.

  • StatusDesign stage — nothing shipped
  • ApproachNarrow and auditable, with a human deciding
  • PrerequisiteData that reconciles — which is the real work
  • First candidateExplaining a settlement figure on demand
  • Also strongSupport drafting, document cross-checks
  • Deliberately notChatbots, and anything that decides unsupervised

What we do not do

A capabilities page that claims everything is useless, so here is the other half. We are not a staffing company and do not place engineers inside your team by the month. We do not run marketing retainers, produce brand campaigns, or sell SEO.

We are also not the right choice if you need a large team mobilised next week. We are small, and the work we are proud of came from being close to the problem rather than from throwing people at it.

If what you need is outside this, we would rather tell you in the first conversation than discover it in the third month.

  • Best fitBooking, scheduling or marketplace products with real money moving through them
  • Also goodRescuing a booking system that works until the rules get complicated
  • EngagementWe build it, then we run it
  • Not a fitStaff augmentation, marketing retainers, large short-notice teams

Describe the requirement

Tell us what breaks today and who it annoys. That is usually enough to work out whether we can help.

connect@pegvix.com