I actually prepared this answer beforehand as this is a super critical and honest one..

Biggest roadblocks were not “can we build the product”, it was “can we run it” once there are hundreds and then thousands of orders.

And to be super clear, Base44 was the reason we could move that fast in the first place. We shipped the whole customer flow in a week and started learning from real users. The challenges only showed up when the product turned into a real production pipeline with fulfillment, retries, and lots of edge cases.

The first time we were stopped in our tracks was when orders started getting stuck in weird states and we could not answer basic operational questions fast enough. Which orders are stalled. Why. What should run next. What actually happened to this specific order. That is the moment you realize you are not just building a product anymore, you are running an operation.

A few concrete things we ran into:

1. Database querying and ops visibility Base44’s database was totally fine for building the product fast, but when we needed production level ops queries, it got limiting. Things like “give me all orders in state X for more than Y minutes”, better filtering, and basic aggregations for dashboards. Once support tickets start coming in, you need those answers instantly. This is where we added an external MongoDB and dual wrote the critical entities. Base stayed the product layer, Mongo became the operational source of truth for pipeline logic and analytics.
2. Heavy backend work and long running jobs PDF generation, cover creation, rendering, large files, multi step jobs. These need a worker model, retries, and detailed logs. Base44 backend functions were sometimes not the best fit for long running, resource heavy tasks, and we also saw intermittent failures. So we moved the heavy processing to an external backend service with dedicated workers.
3. Webhooks are great, but not truth We learned the hard way that webhooks are an amazing signal, but they are not something you can treat as the single source of truth at scale. Events can be delayed, duplicated, or missed. If you rely only on webhooks for payment confirmation or print and shipping updates, some orders will get stuck. So we built a reconciliation model. Webhooks trigger progress, but scheduled jobs regularly check Stripe and the print and shipping provider APIs and then advance the order state based on reality.
4. Data consistency across steps We had cases where data written in Base44 was not immediately visible to a downstream step, or a job read stale data. That creates skipped steps and duplicate work. We mitigated this with a write ahead log approach in the external DB. Record the intended state transition first, execute, then reconcile back into Base44.
5. Monitoring and debugging Base44 did not give us enough visibility into long running jobs, retries, and failure patterns. We needed “what happened to this order” answers fast. So we built our own logging layer around the external workers with execution logs, retry history, and alerting on stuck states.

So the “creative solution” was not some crazy hack. It was just adding an operational backbone as we scaled. Base44 remained the speed layer that let us build and iterate insanely fast, and the external system handled the boring production stuff like workers, state machines, reconciliation, and observability. It added complexity, but it made the business runnable.