At Credflow, as we started integrating with more ERPs and payment gateways, we encountered a surge in high-velocity transactional data—invoices, payment confirmations, and ledger updates flowing in near-real-time. Initially, we stored this data in PostgreSQL, assuming its ACID guarantees and relational structure would help us maintain consistency and queryability. However, as data volume grew—especially during GST reconciliation periods—we began seeing serious performance bottlenecks, increased I/O latency, and query failures under load. Our RDS instance was scaling vertically, but the costs were escalating, and more importantly, write throughput became the limiting factor. With limited data on future data patterns and under pressure from the product team (who needed the data accessible for analytics), we had to decide quickly: Should we invest in scaling our relational database and optimize queries, or redesign the architecture to handle high-velocity raw data more efficiently? I made the call to offload raw, high-frequency events to Amazon S3 as a data lake, using a combination of: 1. S3 for ingestion & long-term storage 2. Glue and Athena for ad-hoc querying 3. A reduced relational model for only the most recent and relevant aggregates needed by the UI Below is my Decision-Making Process: 1. Assess access patterns: 95% of the time, our app only needed the most recent 30-day data. Historical data was queried infrequently. 2. Evaluate ingestion throughput: S3 could handle concurrent ingestion from our ETL pipelines at scale without write contention. 3. Prototype a pipeline: Within 3 days, we built a prototype where raw data went to S3, partitioned by client and date, with metadata updates pushed to Postgres. 4. Mitigate risk: Set up Athena queries and a fallback to our existing DB to ensure zero downtime during the transition. 5. Involve stakeholders: Worked with analytics and engineering leads to validate this didn't break downstream dashboards or reconciliation flows. What I Learned: 1. Not all data needs to live in a database. Treating data based on its value, access frequency, and structure helped us optimize both cost and performance. 2. S3 isn't just a storage bucket—it can be part of your real-time architecture if paired with the right tools (Glue, Lambda, Athena). 3. Decoupling write-heavy systems from read-optimized systems was a mental shift that improved resilience and made future scaling much easier.
One way to handle tough tech decisions with limited info is to narrow the risk early. Instead of waiting for all the answers, set up quick technical spikes or PoCs to test assumptions—things like integration complexity, performance bottlenecks, or API maturity. That small upfront investment often saves months of guessing. When choices are close—say between two frameworks or platforms—it helps to frame the decision around what's easiest to change later. Go with the option that reduces long-term lock-in or makes future rewrites easier. A good habit is to involve both senior engineers and product folks early, so technical trade-offs and business impact are visible side by side. Even with half-baked data, this keeps the conversation grounded in value, not just preference. The biggest learning? Delay is often worse than the wrong call. It's better to commit, monitor, and course-correct quickly than to wait for perfect clarity.
As a CTO, I've had to make some tough decisions about whether to adopt an entirely new cloud platform despite having limited knowledge of its long-term viability. The startup was scaling up quickly and was short of infrastructure capacity. I had timelines and deadlines to meet, but I had little information from vendors, so I consulted my key tech team, studied case studies from competitors, and weighed the risks against the gains. Ultimately, I decided to implement the platform gradually to assess its performance and scalability without committing to a full rollout. It has provided us with the flexibility we need while minimising the risks involved. I learned lessons about balancing data-driven analysis with well-calculated risks and the importance of an iterative approach when faced with incomplete information. It reaffirmed the need for decisive leadership combined with adaptability in tech strategy.
One tough decision I faced was whether to migrate a legacy monolith to microservices with limited data on long-term impact. The system was struggling to scale, but a full rewrite risked disrupting development. Instead of an all-or-nothing approach, I opted for a strangler pattern—gradually extracting services while measuring performance, DevOps overhead, and team adaptability. By running small experiments first, we mitigated risk while keeping the core system stable. The key lesson? Perfect information is rare, so progressive, reversible steps often beat high-stakes bets. The experience reinforced that technology decisions are really about people and risk management. A flashy architectural shift might have backfired without team buy-in or clear business alignment. By prioritizing incremental wins and transparent communication with leadership, we modernized the system without sacrificing stability. The biggest takeaway? A leader's job isn't to eliminate uncertainty but to navigate it with a balance of conviction and adaptability.
When I was CTO at a past company before founding Parachute, we faced a tough decision about building a new mobile app. Some engineers pushed hard for native development with Swift and Kotlin, while others backed React Native. A few were excited about Flutter, even though it was still fairly new at the time. I knew that without a clear process, the decision would drag on and leave people frustrated. I started by setting up a RACI matrix. I made it clear that I was responsible and accountable, but that the engineering and product teams would be consulted. Marketing and finance teams were informed but not involved in the technical choice. I opened a Notion document and wrote out everything we knew — product strategy, user research, technical constraints. I told the team to focus only on this task for three days. They could read, prototype, and add comments on their own schedule. No meetings were needed unless someone got stuck. I also held a silent meeting where everyone read the document and added feedback without speaking. It gave the quieter team members space to share their thoughts. After three days, we reviewed the input. Most of the team leaned toward React Native because it fit our timeline and team skills best. There were trade-offs, but everyone had a voice. The biggest lesson I learned was that making space for quiet voices changes everything. If I had just called a big meeting, only the loudest would have been heard. Giving time, space, and clear roles meant the team could disagree and still commit. In the end, we made a good decision faster than expected. Now at Parachute, when we help clients through tough IT choices, I always start by making sure every voice has a place before making the final call. It builds trust, even when not everyone gets their first choice.
The tough decision that I often have to make is around what tech stack and how much time and effort go in to MVPs. When creating a new product, you can't treat it with the same level of rigor as you do a production piece of software. Until you know the product will work and you get paying customers, you can't just the spend on ensuring your following full DRY principals, have a deployment pipeline, fully cover unit, component and integration tests etc. The problem here is, when that MVP does get market proven and becomes a real product, you have to go back and fix up all of those short cuts you made. Keeping the balance between doing things the right way on MVPs and getting them to the market as quickly as possible is tough. I've learned that you need to go somewhere in the middle. It's fine not to have a full deployment pipline with CI/CD, but you do need a level of testing for instance.