OMSTA — ERP and mobile app for a travel agency

01Context

OMSTA is the system CristegnoViajes SRL, a travel agency in the Dominican Republic, runs on. The agency sells hotels, flights, packages, cruises, insurance and other services, gets paid in pesos and dollars, pays its suppliers, runs payroll and files with the DGII, the Dominican tax authority. It operates two branches, Santo Domingo and Santiago, on a single platform.

The first commit dates from April 2025. Today the web app is in production and 15 people use it every day, and since September 2026 the team also has its own mobile app.

02The problem

An agency ties together three worlds that usually live apart: sales, money and accounting. When each one lives in a different tool, the same data gets typed in several times, balances don't match and nobody can reconstruct what happened to a booking.

The challenge was to capture a sale exactly once and have everything else follow from it without retyping a thing: the payment, the NCF tax invoice, the journal entries, the supplier payable, the bank movement and the tax reports. And to let the team do their part away from the office, too.

03My role

I'm the system's only developer: I modeled the domain, designed the architecture, built the backend, the web interface, the API and the mobile app, and I handle deployment, maintenance and production incidents. The repository has more than eleven hundred commits.

04Users and permissions

Five base roles — super admin, admin, accounting, bookings and clients — with individual modules on top that extend what each user can see. An agent creates bookings and records payments; accounting verifies them, invoices and closes; admin manages users, branches and settings. Permissions are enforced on the server, by URL prefix, and never depend on what the interface happens to hide.

05Constraints

• Dominican tax rules: NCF receipts from authorized ranges and the 606, 607, 608 and 623 formats. The system prepares, validates and exports; a person does the actual filing with the DGII.
• Multiple currencies: every payment keeps the rate it was collected at, and every layer balances against its own total.
• Accounting invariants: receivables never go into credit, a posted entry is never rewritten and a closed period accepts no new entries.
• Sensitive data: payment receipts live in private storage behind signed URLs.
• A single developer: the infrastructure had to stay small and predictable.

06How I built it

By domain and by layer: bookings and clients first; then the services that move money; then the general ledger and, finally, tax reporting. Views orchestrate, services open the transaction and post the entry, selectors read, and the invariants live in the model and in database constraints, because repair commands don't go through forms.

The boundaries between domains are guarded by tests: the ledger doesn't import accounting, bookings talks to accounting through a neutral contract, and the public surface of the largest models can only shrink. Every change goes through lint, formatting, Django checks, migrations and pytest on GitHub Actions before it ships.

07Architecture decisions

• A modular monolith, not microservices. A one-person team and transactions that cross domains call for a single process with clear boundaries.
• Server-rendered HTML. No SPA and no build step: Bootstrap, jQuery and HTMX over Django templates, with the logic only in the backend.
• Django Q2, not Celery. PostgreSQL is the single source of truth, job state included; Redis is queue, cache and sessions, and it can be lost without losing business.
• An atomic accounting package. Issuing an invoice posts the sale, cost, advances and payments in a single service.
• An immutable tax snapshot. What was reported to the DGII doesn't change, even if the source data changes later.
• The app doesn't calculate. The server sends it formatted amounts, statuses with their labels and even the shape of the forms.

08The mobile app

The web app used sessions and CSRF, and there was no API designed for a client outside the browser. I built a dedicated REST API with JWT bound to each device (with rotation and a blocklist), an OpenAPI contract generated with drf-spectacular, and the app's TypeScript types generated from that contract: if the API and the app drift apart, continuous integration fails.

The app is built with React Native, Expo and TypeScript. It has 54 screens: a home screen with the month's key numbers, bookings with their record and a step-by-step creation wizard with drafts and a custom calendar, clients, payments, alerts, catalogs and administrative settings. It unlocks with the phone's biometrics, stores tokens in the system keychain, works offline from a persisted cache and records payments with a photo of the receipt using the same service as the web.

The API and the app were built in sixteen days, between September 10 and 25, 2026. Today they're distributed as internal Android builds through EAS and tested on a real phone. The project is already set up for iOS; the iPhone version is waiting on the business's Apple Developer account.

09Challenges

Money crosses three domains — bookings, accounting and the ledger — and a payment can be applied, corrected, reversed or leave an overpayment. Keeping idempotency and integrity intact across all those paths was the hardest part. Close behind: Dominican tax rules, and reducing the natural coupling of a large monolith without slowing down daily operations.

10Real incidents, solved

• Payments submitted twice: every payment carries an idempotency key with a unique constraint in the database; a retry returns the payment that already exists.
• An app retry came back as "possible duplicate payment" because the form validated before the service did. Now the key is resolved first.
• Broken PDFs in production because of system libraries WeasyPrint needed: the deploy image now installs them at build time and at runtime.
• A health check behind the login made Railway treat a healthy deploy as down: /health/ is now exempt from login and from the HTTPS redirect.
• A discount applied to an already-paid booking created a correct credit balance, but nobody found out. I fixed the notice on save and the receipt, and added a read-only diagnostic to audit overpayments.

11Design and UX

The dashboard puts first what drives the day: bookings, payments, commission, balances and alerts that lead to action. The booking record separates sales status from payment status and shows the status ladder, the percent collected and the balance. The six product types share the same entry pattern, with section navigation and a live price summary.

Accounting stops being a black box: each entry explains in plain language what it records, and the booking shows all of its own entries. A posted payment isn't edited; it's corrected through a guided flow or refunded. And below 768 px, tables turn into cards.

12About the screenshots

Every screenshot comes from an isolated database, seeded with synthetic data by the same services the system uses: invented names, example emails and fictional tax documents. None of them show data from the agency or its clients. Screens that showed a bug or weren't finished were left out.

13What I learned

In software that handles money, communicating the result matters as much as calculating it. Invariants have to live in the model and in the database, not in forms. Idempotency comes before validation: otherwise, a retry looks like a duplicate. And reusing the web's service from the mobile API avoided having two versions of the same business rule.

14Current status

The web app is in production and used every day. The mobile app is in active development: bookings, clients, payments and alerts already work on a real phone, with push notifications and the app store releases still ahead. Current work focuses on a phased accounting audit and on paying down technical debt without interrupting operations.

15Next step

The repository is private because it's a client's system. If you need a platform that connects operations, money and accounting with real traceability, on the web and on the phone, you can get in touch.