Documented technical decisions
A record of decisions made in Paraguay during the development of our own products in validation: what was evaluated, what was decided, and why.
A decision record isn't a case study or a general guide: it's the record of a specific technical decision, with the alternatives that were evaluated and the reason one was chosen over another. 13 decisions documented so far, between Pymerce and Pyae.
Pymerce decisions
- Multi-tenancy ready without overengineering
- Data access is centralized through a tenant context from the MVP, without depending on a single database in the code.
- Inventory by location, not a global product count
- Inventory is modeled transactionally by location and product, with a full history of movements.
- Separating the tax filing from the sale itself
- The sale is confirmed before the communication with the tax authority runs.
- Deciding through a technical test, not an assumption
- Foundational decisions are validated with reproducible technical tests before they're locked in.
- Building our own authentication instead of using an external provider
- In-house authentication is implemented with protected sessions, signup, and secure recovery.
- Not building a separate wholesale mode
- Retail and wholesale are treated as profiles of the same domain, without duplicating logic.
- Deferring features until the initial profile is validated
- Purchasing, stock alerts, and other capabilities are postponed until the core flow is validated.
Pyae decisions
- Per-restaurant session isolation
- Access and sessions are resolved per restaurant, identified by its own tenant.
- Real-time updates for kitchen and orders
- Order and kitchen status changes are pushed in real time, scoped per branch.
- Messaging integration decoupled from the domain
- Messaging is defined through a replaceable adapter layer, with a test double available.
- Idempotency and locking to prevent duplicate orders and payments
- Persisted idempotency and distributed locking are applied to orders and payments.
- Separating order status from payment status
- Delivery is evaluated by outstanding balance, not by the sale's overall status.
- Modifying an in-progress order without corrupting its total
- Items are added and the order is recalculated within a single transactional operation with retry.
Frequently asked questions
- What is a decision record?
- It's the record of a specific technical or product decision: which alternatives were evaluated, which one was chosen, and why. It's not a case study or a general guide — it's evidence of a criterion applied in real development.
- Why does Flexora publish its technical decisions?
- To show the reasoning behind software development, not just the final result. The records in this section correspond to Pymerce and Pyae, two of Flexora's own SaaS products built in Paraguay and still in validation.
Need technical decisions this clear for your project?
We document and sustain technical decisions with the same rigor in the custom software we build for companies.