A selection of projects in production.

Real-world cases reflecting the experience built in systems development and integration.

Quantix | Multi-Company Inventory and Billing Core

Centralized inventory and billing platform that lets multiple companies and branches operate from a single system, eliminating fragmented data and duplicated administration.

Problem

Organizations with multiple companies and branches needed inventory, billing, reporting, and configuration under one operational core without fragmenting data or setup.

Solution architecture C# / .NET implementation Multi-company model

Stack

C# .NET Azure SQL Database

Architecture snapshot

  • Clean Architecture core for inventory, billing, reporting, catalogs, and configuration.
  • Multi-company and multi-branch model with isolated operational context inside one shared platform.

Impact

  • One installation can manage from one to many companies and their branches.
  • Inventory, billing, and reporting now run through a clearer shared daily workflow.
Read case study

Watch video

Quantix in production

A real walkthrough of the system showing the multi-company operational core, billing flows, and daily management context.

Context

Quantix was built as a production system for businesses that need inventory and billing control across multiple companies and branches without duplicating platforms.

Solution overview

  • The platform was organized into inventory, billing, reporting, catalog, and configuration modules on top of a .NET backend.
  • The C# client was shaped around company and branch context so teams could navigate the same core without duplicated flows.
  • The data layer was centralized on Azure SQL Database to preserve traceability, consistency, and consolidated reporting.

Outcomes

  • Multiple companies now operate on one platform with branch-level control.
  • Critical modules share one source of data for inventory, billing, and lookup workflows.
  • The system can expand with new catalogs, reports, and settings without breaking the operational core.

Constraints

  • Each company had to coexist in the same system with its own rules, catalogs, and configuration.
  • Inventory and billing required consistent data and reliable responsiveness in daily operations.
  • The platform had to grow by modules without turning the user experience into a fragmented system.

Key decisions

  • A shared multi-company core was prioritized over isolated customer-specific deployments.
  • Company separation lived in the data and configuration model, not in separate application instances.
  • Azure SQL Database was chosen to support transactional consistency and cloud-based operational scale.

Lessons learned

  • In multi-company systems, getting context and configuration right matters more than piling on screens.

LS Central Statement Insufficiency Control

Custom insufficiency-control module built in AL on Business Central to identify statement shortages and stop Post Statement until inventory is corrected.

Problem

LS only stopped Post Statement with a generic negative-inventory alert, leaving operations without the exact items and quantities needed to correct the statement before posting.

Functional analysis AL architecture Page extensions + post guard

Stack

AL

Architecture snapshot

  • Two page extensions: one on Open Statement for the operational entry point, another on setup to control insufficiency behavior and feature flags.
  • Dedicated calculation and guard codeunits separate UI, business rules, and posting protection inside the LS flow.

Impact

  • Operations moved from a generic stop message to an exact insufficiency list for the selected statement and date.
  • Teams can adjust inventory or execute corrective movements before posting, keeping statements and inventory cleaner.
Read case study

Watch video

Operational walkthrough

Visual walkthrough of the operational flow used to review statement shortages before posting.

Context

Built for a Nicaraguan company running Dynamics 365 Business Central with LS Central BackOffice and POS, where nightly statement closure needed more than a blocking alert.

Solution overview

  • Added an Insufficiencies action through a page extension on Open Statement to open a statement-scoped list of insufficient items.
  • Built a second page extension on the existing setup so the company could enable or disable posting block and complementary insufficiency logic.
  • Implemented dedicated AL codeunits for calculation and post guard, including the validation that stops Post Statement when insufficiencies still exist.
  • Added operational trace and export capabilities so users could move from alert to correction with concrete evidence per item.

Outcomes

  • Users can now see every insufficient product tied to the current statement before attempting posting.
  • Inventory adjustments and corrective movements happen with real statement-level evidence instead of guesswork.
  • Nightly closing became cleaner because posting is stopped only after presenting actionable insufficiency detail.

Constraints

  • The feature had to live inside Open Statement so the nightly operation would not depend on external screens or manual workarounds.
  • The solution had to explain the exact insufficiencies for that specific statement and date, not just signal that something was wrong.
  • Business rules had to remain configurable through setup, including posting block behavior and deeper calculation logic.

Key decisions

  • The feature was embedded in the LS BackOffice page instead of a detached process, maximizing adoption in the real nightly workflow.
  • Setup, UI entry point, calculation engine, and posting guard were separated to keep business rules maintainable and auditable.
  • Actionable evidence per statement was prioritized over the generic native message because operations needed to fix inventory before closing.

Lessons learned

  • In retail backoffice flows, blocking alone is not enough; the system must explain the problem exactly where the user can resolve it.

NicaFinance | Web-first Financial Education Platform

Applied financial education platform helping people in Nicaragua understand their salaries, loans, and labor rights through practical tools and AI assistance.

Problem

Traditional financial tools often deliver results without explanation, leaving users alone to make decisions that can have serious economic consequences.

Stack

Flutter Dart Hono Cloudflare Workers OpenAI

Architecture snapshot

  • Feature-first Flutter frontend with a reusable design system and responsive shell.
  • Decoupled edge backend running on Cloudflare Workers (TypeScript + Hono).

Impact

  • Democratizes practical financial education for users with limited economic expertise.
  • Reduces information asymmetry in sensitive decisions like loans or severances.
Visit website
Read case study

Context

A digital product built specifically for Nicaragua to close the gap between numbers and understanding on loans, salaries, and severances.

Solution overview

  • Built contextual calculators that guide the user explaining risks and key points alongside the numbers.
  • Integrated an AI assistant to clarify specific doubts and steer the user toward specific internal tools.

Outcomes

  • The platform is fully live, transforming complex calculations into actionable, safe advice.
  • Demonstrates robust end-to-end execution, spanning from the UI design to AI and Edge computing.

Constraints

  • Users often lacked the technical or financial background to interpret raw calculation results safely.
  • Needed a robust local context specific to Nicaraguan payroll, labor rights, and banking practices.

Key decisions

  • A serverless Edge architecture was chosen for the backend to ensure low latency and scalable OpenAI integration.
  • Offline-first principles and local persistence were favored to keep session data out of external databases.

Lessons learned

  • Developing products with real social utility proves stronger engineering judgment than merely tracking latest hypes.