Stackly

Sandbox
Movements

Inspiration

A business can look healthy on paper and still be one unexpected event away from a cash crisis.

Sales may be growing. Profits may look strong. A company may even win its biggest project yet. But behind those numbers there can be hidden vulnerabilities: too much revenue coming from one customer, payroll arriving before invoices are collected, or a single delayed payment turning a profitable month into a liquidity problem.

The problem is that traditional financial analysis often tells a business how healthy it looks today. It does not always tell the owner what could break tomorrow.

That is the problem we wanted to solve.

Stackly was built around a simple question:

Before I make this decision, how much room does my business really have — and what would make it fail?

Instead of giving an abstract risk score, Stackly turns a business decision into something an owner can understand and act on: how long the business can hold out, what obligation would become uncovered first, why it happens, and what can be changed to strengthen the situation.

The goal is not to tell business owners what decision to make.

It is to help them make that decision with a clearer view of what is at stake.

What it does

Stackly is a resilience simulator for business decisions.

A business owner can explore decisions such as:

Accepting a new project
Extending credit to a customer
Hiring additional staff
Purchasing an asset
Requesting financing

Stackly then puts that decision under pressure through different scenarios, such as:

Customers paying later than expected
Losing the company's main customer
Injecting additional capital

The result is not simply "high risk" or "low risk."

Stackly answers four questions that matter when money is on the line:

How long can I hold out?

Stackly shows how many weeks the business can continue before an obligation can no longer be covered.

What breaks first?

Instead of showing an abstract warning, it identifies the actual obligation that becomes uncovered — including what it is, when it happens and how much money is missing.

For example:

"Payroll on November 26 is uncovered by $40,000."

That turns a risk indicator into something a business owner can act on.

Why does it happen?

Stackly breaks the situation down across the factors that put pressure on the business: payroll coverage, collection periods, customer concentration, tolerance to delays, cost increases and sales reductions.

This makes the result understandable instead of leaving the user with a black-box score.

What can I do about it?

The system searches for the smallest reinforcement that improves the company's resilience and shows how that change propagates through the business:

Delivery → Invoice → Collection → Cash → Payroll

This is important because the most intuitive solution is not always the best one.

In our documented scenario, simply delaying purchases or hiring gradually actually made the situation worse because both decisions added additional pressure before the company collected its revenue.

The engine found that the minimum reinforcement was a 25% advance, reducing the frequency of cash gaps from 46.9% to 4.6%.

That is the kind of insight Stackly is designed to surface: not just that a decision is risky, but how to make it safer.

Real data behind the experience

Stackly is not limited to a single fictional company.

The product includes a company catalogue and a movements ledger backed by PostgreSQL and TimescaleDB through Tiger Cloud, allowing the same analysis experience to work with a real historical reference set.

The current dataset contains more than 43,000 companies, almost 676,000 financial movements, and more than 2,000 recorded bankruptcy outcomes.

This gives us a foundation for moving from a compelling simulation toward a system that can eventually learn from real business behavior.

How we built it

We designed Stackly around one principle:

The experience should feel simple even when the problem underneath is complex.

The architecture allows us to keep the business logic, simulation engine, data and user experience independent while still working together as a single product.

The system is built as:

Browser → CloudFront → API Gateway → Go services → Python simulation engine

The frontend is built with React, TypeScript and Vite, including an interactive resilience visualization that lets users see how the company's situation changes as they modify a decision.

The core business logic lives in Go, while Python and NumPy power the financial simulation and scenario analysis.

The engine is deterministic for a given scenario. This means the same inputs always produce the same result.

That seemingly simple property gave us a major advantage: results can be safely cached, making repeated scenarios extremely fast and making the application reliable even under the constraints of a hackathon environment.

The simulation itself can evaluate thousands of possible futures and identify how different decisions affect the company's resilience.

Infrastructure

The application runs on AWS using a lightweight, serverless architecture:

Amazon S3
CloudFront
API Gateway
Two ARM64 Lambda functions
GitHub Actions with OIDC
Automated budgets and alarms

We deliberately avoided infrastructure that would add significant operational cost without providing value for the current stage of the product.

The result is a complete production-style backend with an infrastructure cost of approximately $1.30 per month, while keeping the architecture ready to grow.

Built for trust

Financial decisions require more than an attractive interface.

Every number displayed by Stackly comes from the simulation engine. The frontend does not invent or independently calculate financial states.

We also built automated checks that protect the integrity of the product, including validation of:

Reproducible datasets
API contracts
Domain boundaries
Product terminology
Financial-state presentation

This means that reliability is not something we leave to manual review. It is part of the product itself.

The database: Tiger Cloud

One of the most important architectural decisions we made was how to handle persistent financial data.

We needed a real relational database because Stackly's next stage depends on working with historical companies, financial movements and outcomes.

Running a traditional managed database inside AWS would have introduced significant infrastructure overhead for a hackathon-sized application: database costs, networking, VPC infrastructure and NAT.

Instead, we chose Tiger Cloud.

Tiger Cloud gave us a managed PostgreSQL environment with TimescaleDB while allowing the rest of the application to remain completely serverless on AWS.

This let us keep the architecture simple:

AWS handles the application. Tiger Cloud handles the financial data.

The result is a real database-backed product without having to build a large cloud infrastructure footprint just to support it.

A real financial data foundation

Our PostgreSQL database currently contains:

43,171 companies
43,169 company snapshots
675,690 financial movements
2,073 recorded bankruptcy outcomes

The movements dataset is managed with TimescaleDB, which is designed for workloads where large volumes of time-based data need to be stored and queried efficiently.

This matters because Stackly's core question is inherently temporal:

What happens to the company's cash position over time?

Instead of treating financial data as a static spreadsheet, we are building a foundation capable of following the company's financial story through time.

From demo data to a product foundation

Tiger Cloud also allowed us to make an important transition in the architecture.

The first version of Stackly could operate entirely from predefined fixtures.

Now, the same business logic can obtain a company profile from PostgreSQL.

That means the engine does not need to know whether the information came from a demo scenario or from the database. The data source can evolve without rewriting the product.

This is an important step toward the future vision of Stackly: a system that can continuously understand a company's financial position instead of analyzing a single manually prepared scenario.

Data integrity matters

Because Stackly deals with financial information, incorrect data can be worse than missing data.

We therefore designed the database around explicit financial invariants: monetary values are stored precisely, duplicate movements are detected, and unknown values are kept as unknown rather than being silently converted into zero.

This allows Stackly to recognize when it does not have enough information to provide a trustworthy answer.

When the available information is insufficient, the product abstains instead of pretending to know.

That behavior is intentional.

Challenges we ran into

Turning financial information into a story about cash

Our historical dataset contains thousands of companies and real outcomes, but it was not originally designed as a cash-flow simulation.

It provided financial ratios, but not the dates, movements or counterparties required to recreate a company's day-to-day cash position.

We had to build a bridge between those two worlds without pretending that derived information was actual reported financial activity.

Every derived movement is therefore explicitly identified as hypothetical.

This distinction is important because a useful simulation must also be an honest simulation.

Knowing when not to answer

We also discovered how sensitive financial models can be to missing information.

When important variables are unknown, confidence can deteriorate quickly.

Rather than hiding that limitation, Stackly incorporates it directly into the product.

When there is not enough information to support a meaningful result, the system enters an abstention state.

In other words:

Stackly would rather say "I don't have enough information" than give a confident-looking answer that the data cannot support.

Making every explanation dynamic

Another challenge was ensuring that the explanations shown to users actually reflected the scenario being simulated.

For example, if a payment arrives on day 76 in the current scenario, the interface cannot simply display a previously written sentence saying that it arrives on day 80.

We therefore made the interface generate its explanations from the actual engine results.

This keeps the narrative synchronized with the simulation and prevents the UI from becoming a collection of hard-coded claims.

Building a reliable demo

A hackathon product has another challenge: it has to work when the environment is not perfect.

Network interruptions, cold starts and WebGL issues can turn a technically correct application into a poor demonstration.

We solved this by preparing real scenario states that allow the product to render immediately and gracefully degrade when the backend is temporarily unavailable.

Even the fallback follows the same principle as the rest of the product:

It never invents a number.

Accomplishments that we're proud of

We turned financial complexity into an actionable decision

The biggest accomplishment is not the technology itself.

It is that Stackly can take a complicated financial situation and turn it into a simple conversation:

How long can I hold out? What breaks first? Why? What can I change?

That is the experience we wanted to create.

Every number has a reason

Every financial value displayed on screen comes from the underlying engine.

There are no manually written results disguised as simulations.

This creates a clear relationship between what the user sees and what the system actually calculated.

We proved that intuition can be misleading

One of the strongest findings from our scenario was that two apparently sensible strategies — staggering a purchase and hiring gradually — actually increased the frequency of cash gaps to around 61%.

The reason is subtle: both strategies introduced additional costs and delayed the moment at which revenue became available.

This is exactly the kind of relationship that is difficult to see in a spreadsheet but becomes obvious when the business is simulated over time.

We chose honesty over impressive claims

We deliberately documented what Stackly cannot claim yet.

We do not claim that the system predicts bankruptcies in Mexico. We do not claim 90% prediction accuracy. We do not present unvalidated probabilities as facts.

We also kept negative results that did not support our hypothesis.

That discipline is important to us because Stackly is intended to support financial decisions.

Trust is more valuable than a bigger number in a pitch.

We built a real product, not only a model

Stackly combines:

An interactive user experience
A deterministic simulation engine
Real historical data
A company catalogue
A financial movements ledger
A serverless cloud architecture
A managed PostgreSQL/TimescaleDB foundation
Automated quality controls

The result is more than a financial model.

It is the beginning of a decision-support platform for business resilience.

What we learned

Determinism can become a product advantage

Making the engine deterministic did more than make testing easier.

It made caching possible, improved the demo experience and gave us reproducible scenarios that could be continuously validated.

The obvious solution is not always the safest one

Business decisions interact with each other.

An action that looks conservative in isolation can create additional pressure somewhere else in the cash cycle.

That is why Stackly focuses on the entire chain rather than evaluating individual decisions independently.

Concrete consequences are more useful than abstract risk

"High risk" does not tell a business owner what to do.

"Payroll on November 26 is uncovered by $40,000" does.

The more concrete the consequence, the easier it becomes to take action.

Knowing our limits makes the product stronger

We learned that saying "we don't know" is not a weakness when the alternative is pretending.

The abstention state became an important part of the product's credibility.

Data quality is part of the product

A sophisticated simulation is only as useful as the information behind it.

That is why our next steps focus not only on improving the model, but also on improving the quality, freshness and traceability of the data that feeds it.

What's next for Stackly

Stackly is currently a powerful prototype. The next step is turning it into a continuously informed decision platform for real businesses.

1. Validate with Mexican SMEs

The most important next step is temporal and prospective validation with Mexican SMEs.

We need to evaluate the system using real companies, historical cut-off dates and future outcomes to understand how well its signals generalize beyond the current benchmark.

2. Connect real financial information

We want to move from manually prepared scenarios toward automatic data ingestion through:

CFDI
Banking connectors
Financial data sources

Each source will carry freshness and reconciliation information so users can understand how current and trustworthy their data is.

3. Learn from the decisions themselves

A recommendation becomes much more valuable when we know what happened afterward.

The next version of Stackly will track whether an action was offered, accepted, its cost, whether emergency financing was needed and whether the business eventually required renegotiation.

This will allow us to measure whether our recommendations actually improve resilience.

4. Build the full business resilience twin

Our long-term vision is to represent a company as a living financial system.

Instead of looking only at cash flow, Stackly can eventually connect different areas of the business and understand how changes propagate through them.

The goal is to identify not only individual risks, but the relationships that make a company resilient or fragile.

5. Move from analysis to proactive alerts

Finally, Stackly can evolve from a tool that owners open when they have a decision to make into a system that proactively tells them when something deserves attention.

Instead of sending the same warning every day, alerts will focus on meaningful changes in severity or upcoming obligations.

The vision is simple:

Stackly should help a business owner see the problem before the problem becomes the emergency.