Internal web applications
Operations dashboards, customer portals, tools for your team. Where the return shows up fastest.
Software development
Custom software, built to last five years
Ten years building systems that ended up in production with real users: loyalty platforms, marketplaces, healthcare, e-commerce and financial-sector applications.
Technical capabilities
TypeScriptNestJSReactNext.jsPython.NET CorePostgreSQLAzureAWS
2M+users on the largest platform we built
10years of software engineering
5sectors: loyalty, healthcare, proptech, retail and financial
Key takeaways
- Custom software is expensive to build and maintain: if an off-the-shelf product covers 80% of what is needed, buying it is the right call and adapting the rest.
- It is justified in four scenarios: the process is the competitive advantage, systems do not talk to each other, per-seat licensing no longer works, or a real regulatory constraint applies.
- Quarl builds internal web applications, transactional platforms, backend and data modelling, and phased modernization of legacy systems.
- Code, documentation, infrastructure and credentials stay in the client's name, with a month of support included after handover.
Operating track record
FEMSA loyalty platform
Three years operating the system in production — not one delivery and an exit.
Cross-entity contamination
The most frequent failure in RAG architectures, solved with structured metadata at ingestion.
Fixed scope and date
The proposal arrives within 48 hours with fixed scope, price and date. If scope changes, it is quoted separately and approved first.
Honesty first
You probably do not need it
We mean it. Custom software is expensive to build and expensive to maintain, and most business needs are already solved by some product costing a fraction. If an off-the-shelf product does 80% of what you need, buy it and adapt the remaining 20%.
On the first call we review what you need and what exists on the market for it. If there is a product that serves you, we tell you which one.
When it is justified
The four scenarios
- Your process is your competitive advantage. If how you operate is what sets you apart, forcing it into a generic product erases exactly that.
- The systems you have do not talk and no product on the market connects them the way you need.
- Per-seat licensing no longer works. When three monthly subscriptions exceed the amortized cost of building your own, the math changes.
- You have a real constraint — regulatory, data residency or integration — that no off-the-shelf product accounts for.
What we build
Typical scopes
Transactional platforms
Payments, inventory, orders, points wallets, notifications. What holds up when volume grows.
Backend and data modeling
The part nobody sees that decides whether the system survives growth.
Legacy modernization
Migrations in stages, without turning off what runs your operation today.
Previous work
Systems in production
| Project | What we built | Scale |
|---|---|---|
| Loyalty platform FEMSA · Mexico and LATAM | Platform from scratch: authentication, points wallet, rewards catalog, transaction history, QR scanning, notifications and the promotions engine. Plus the AI assistant. | 2M+ active users · 10 countries · 99%+ uptime |
| Real estate marketplace Proptech · United States | Real-time layer: WebSocket messaging, geolocation search, multi-criteria filtering and rent payment processing. | 10,000+ tenants and landlords |
| Full e-commerce | Zero to production in six months: microservices API, web storefront and mobile app with the complete purchase journey. | Launched on schedule, no prior codebase |
| Financial sector | Backend services, refactoring of critical queries and removal of bottlenecks in legacy modules. | Agile team of 8+ engineers |
Stack
What we build with
TypeScriptNode.jsNestJSReactNext.jsAstroReact NativeExpoPythonFastAPI.NET CoreC#PostgreSQLGraphQLWebSocketsDockerAzureAWSGoogle CloudGitHub Actions
Related services
Integrations and APIs
MCP servers against the systems already in operation.
View serviceMobile applications
iOS and Android, with inference on the correct side.
View serviceAI automation
Applied where there is volume and stable rules, not where there is expectation.
View serviceAI consulting
Architecture, evaluation criteria and cost per query before writing code.
View serviceFrequently asked questions
How do you decide between custom and buying a product?
On the first call we review what you need and what exists on the market. If a product covers 80%, we tell you which one and how to adapt the rest. We would rather lose a large project than build something you will regret maintaining for five years. Custom is justified when the process is your advantage, when systems do not talk, when licensing no longer works, or when there is a real regulatory constraint.
How is it quoted?
Price is driven by the complexity of your operation rather than the number of screens: how many processes have to be modelled, how many systems it integrates with, and what availability or regulatory requirements apply. The proposal arrives with fixed scope, price and date within 48 hours of the call, and that call is free.
How do you handle large projects?
Split into phases with independent deliverables. You can stop between phases, and we have to demonstrate value in each one. It is more demanding for us and far less risky for you than a six-month contract with delivery at the end.
What if scope changes?
It is quoted separately and approved before execution. It never appears as a surprise on the final invoice. Scope changes are normal in any real project; what is not normal is finding out at payment time.
Do we own the code?
Yes, always. Code, documentation, infrastructure and credentials stay in your company’s name. We include a month of support after handover and after that maintenance is optional and quoted separately. We do not work with arrangements where the client depends on the vendor to keep operating.
Do you work with our internal team?
Yes. We can take the full project, join your team as reinforcement, or pair with your engineers with the explicit goal of leaving capability behind. If you already have technical people, the last format usually delivers the most value over the medium term.
What stack do you use and why?
TypeScript with Node.js and NestJS for backend, React and Next.js for web, Python when there is a data or AI component, .NET Core when the client environment calls for it, PostgreSQL as the default database. The choice is justified by the case, not by preference — and if your team already works with something, we respect it.
Do you include AI in software projects?
When it adds value, yes, and with the same measurement discipline we apply to purely AI projects. What we do not do is add AI because it is fashionable: if a well-built query solves the problem, that is the right solution and it costs a fraction.
Book 15 minutes
Tell us what you are building, or what stopped working. You leave the call with a concrete answer: it can be fixed, it can be built, or it isn't worth it.