Latest news with #platformengineering
Forbes
18-07-2025
- Business
- Forbes
Scaling Fintech Startups: Lessons From Hypergrowth Engineering
Madhuri Sesha Sarma is a VP of Engineering at Carta. With over a decade working in the fintech ecosystem at companies like Visa, Clover, Fiserv, and now Carta, I've seen how fintechs face unique challenges when it comes to hypergrowth. Few industries match fintech's growth, but rapid expansion in this sector often brings hurdles that hinder execution velocity and product quality. I recall at one company, for example, how we'd face outages every Friday due to peak dinner payment volume or the pressures of holiday seasonality. Over the years, I've learned that scaling a fintech from 0 to 1 and then from 1 to N requires a focused platform engineering strategy. Let's explore some key factors for this strategy: Build for modularity early. A 0-to-1 product can work with a monolith, but a monolithic architecture can become a liability at scale. It can lead to all-or-nothing deployments, slow delivery, complicate debugging and often undermine reliability. Building modularity early via microservices or well-defined domains within a monolith supports scalability. For fintechs processing high volumes of payments, isolating core payment logic into a highly available service ensures critical operations remain stable even if non-essential features experience issues. For a deeper understanding of the challenges that companies face with monoliths while scaling, an excellent resource is an essay by Marco Palladino, co-founder and CTO of Kong, where he shared his challenges with monoliths and insights about his company's journey to modularity. Prioritize execution velocity. As usage scales, product development slows, bogged down by growing needs for quality assurance, incident response and compliance. Traditionally, this leads to heavy processes: manual regression testing, gated releases, and risk-averse cycles. While these methods help manage risk, they can strangle velocity over time. Instead, teams should invest in automation and tooling that embeds quality and risk controls into development workflows. Examples include: • LLM-powered integrated development environments (IDEs) like Cursor and Windsurf add tests to every pull request. • Automated quality gates in CI/CD pipelines. • Alert pruning, intelligent incident tracing. • Canary deployments and automated rollbacks. This approach helps to maintain speed while addressing complexity at scale. Maintain a two-speed engineering model. As a startup grows, chances are there is a critical legacy application that is moving at a much slower pace, as compared to newer products or applications that essentially need to move at a high velocity. In this scenario, adopt a two-speed engineering model, where applications evolve and release at different rates aligned to risk tolerance, innovation needs and the desire for rapid feedback. Ensure quality assurance and deployment cycles are tailored to the specific needs of each stack. Scale infrastructure with observability, not guesswork. In fintech, reliability is non-negotiable given the financial impact of incidents. Yet, observability is often sidelined until after a critical incident forces urgent attention. To avoid this reactive cycle, teams must treat observability as a core product requirement, not a bolt-on. This requires a shift in mindset. At the outset, teams should define service-level indicators (SLIs) and error budgets that align with business priorities. Encouraging 'you build it, you own it' accountability ensures developers see value in adding telemetry early. Then, consider leveraging the LLM capabilities in observability tools such as Datadog Bits AI that integrate into CI/CD. Investing in observability early pays long-term dividends, not only in uptime and user trust but in enabling confident, data-driven scaling as your fintech grows. Treat compliance and security as first-class citizens. Historically, prioritizing security and compliance almost always included a velocity tradeoff. A 2023 Palo Alto Networks report found that three-quarters of organizations publish new code to production weekly. Now, with the evolution of secure software development solutions in the market, the tradeoff is no longer relevant, and embedding security into software development should no longer be an afterthought. Tools such as Veracode, Snyk, Wiz and others can detect and alert users about security vulnerabilities. AI-era security tools now offer AI copilots that can integrate with IDEs to automatically scan code for vulnerabilities and recommend remediation before the change gets committed into the source repository. Design for data security and portability. A 2025 Alloy report involving over 500 banks, credit unions and fintechs found that 60% of financial institutions reported an increase in fraud, and nearly a third incurred over $1 million in direct fraud losses. A data breach can be severely consequential to both the consumer and the fintech, especially when you consider that fintechs often deal with some of the most sensitive consumer data. Data security investments such as investing in data encryption, data security posture management tools and ensuring access to data is granular, audited and only on an as-needed basis can protect the sensitive customer data from internal and external threats. Additionally, as the data read and write load increases, strategies such as sharding can ensure the data source is reliable and can cater to increased usage. Avoid the platform trap. While a robust platform strategy is essential for long-term scalability, fintechs in hypergrowth must resist the temptation to over-engineer too early. Premature investment in shared services can lead to wasted effort and unused systems. Instead, build for scale as needs emerge, when multiple teams experience repeatable friction or request common solutions. Ensure there's a clear pull before investing in platform features. Overbuilding too soon slows agility and adds debt. Successful platforms are born from demand and prioritize validated needs over hypothetical scale. Closing Thoughts Investing in foundational architecture and organizational strategies early can help ensure that fintech startups can scale well beyond early success. With these strategies in place, growth-stage fintechs can leverage their resources and expertise to build the next phase of high-scale products. Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
Forbes
29-06-2025
- Business
- Forbes
Platform Engineering At A Crossroads: Golden Paths Or Dark Alleyways
Following the golden path to platform engineering success is not without its pitfalls and pernicios ... More passageways. getty Automation equals efficiency. It's a central promise that's now permeating every segment of the software application development lifecycle. From robotic process automation accelerators that work at the user level, through encapsulated best practices applied throughout the networking connection tier used to bring applications to production… and onward (especially now) to the agentic software functions that can take natural language prompts (written by developers) and convert them to software test cases and, subsequently, also write the code for those tests. Automation represents a key efficiency play that all teams are now being compelled to adopt. As an overarching practice now carrying automated software development tooling forward, platform engineering is widely regarded as (if not quite a panacea) an intelligent approach to encoding infrastructure services and development tools in a way that means developers can perform more self-service functions without having to ask the operations team for backup. Platform engineering encapsulates the deliberate design and delivery of internal software application development tools, services and processes that define how software engineers build software. It's a holistic approach that covers the underlying processes, people and (perhaps more crucially of all), the cultural workflow mindset of an organization. At the keyboard, platform engineering is not necessarily all about implementing new technologies (although the omniscient specter of agentic AI will never be far away); it's about fostering consistency and a shared understanding across diverse teams. Devotees who preach the gospel according to platform engineering talk of its ability to lead towards so-called "golden paths" today. These can be described as standardarized workflow routes where infrastructure and configuration parameters for software development are encoded, ratified and documented. Often referred to as an 'opinionated' software practice (i.e. one that takes a defined path and does things one way, not the other way) that help individual software engineers stay close to tooling and processes that will be used by all other developers in a team or department. 'One way to think of a golden path is to imagine baking a cake. The steps required to bake a cake include pre-heating the oven to a specific temperature, gathering the right baking tools… and having the necessary ingredients. It's more than following a recipe, it's also making sure you use the right tools and techniques. If you want more people to bake the same cake, you find ways to become more consistent and efficient, explains Red Hat , on its DevOps pages. According to Derek Webber, VP of engineering at AI-enabled software quality engineering company Tricentis , platform engineering does have the potential to be golden, but it can also lead teams down a dark and dusty track into the Wild West. Why The Wild West? 'Yes, the promise of platform engineering lies in creating golden paths for software delivery. However, the absence of a traditional structured approach to software development often leads to what can only be described as the 'Wild West' of software development, particularly within large, scaling enterprises,' stated Webber. 'In such environments, each product team might independently craft their own unique pipelines, tools and processes. While this might afford initial autonomy, it inevitably leads to fragmentation. As organizations grow from a few dozen to hundreds or thousands of engineers, the tight-knit integration and level of shared understanding that characterizes a startup are lost. Developers become isolated, building 'unique snowflakes' of software pipelines that are difficult to maintain, understand and transfer knowledge across.' This fragmentation might be argued to severely hamper an organization's ability to be flexible and nimble, with an ability to move fast (remember the pandemic, yeah, that kind of change). Why would this be so? Because every new feature, every bug fix and even basic team reorganization becomes a slower and more laborious task. This can happen because of cross-team dependencies when everything is so formally encoded, it can happen because developers see their work as a project, rather than it being a product… and it can happen simply as a result of poorly documented tools in the platform engineering firmament. A fragmented coding landscape also obviously presents challenges to an organization's security posture, making it more difficult to ensure consistent compliance and vulnerability management across all services. DevEx, The Software World On Time 'The true power of platform engineering, especially when championed by a dedicated developer experience (DevEx) team, comes when it is able to balance two critical, often conflicting, objectives: speed and quality. This can be achieved by providing the necessary checks and balances that promote operational consistency and efficiency at scale,' said Webber. 'A core tenet of effective platform engineering is, therefore, the integration of testing from the outset to ensure quality is inherent, not an afterthought. While the industry has long advocated a 'shift left' approach, empowering developers to take on more testing responsibilities earlier in the development lifecycle, it's vital not to overcorrect.' Shifting everything left without considering the end-to-end product can lead to a different kind of fragmentation further down the line. The suggestion here is that platform engineering, via, through and under the auspices of a DevEx team, enables a more holistic approach. Webber says he's convinced that the DevEx team plays a pivotal role in creating a consistent testing framework when applied in the realm of platform engineering. It works by providing developers with readily available, uniform tools and processes. It bridges the gap in domain knowledge that often plagues large organizations, ensuring software engineers have the context needed to build robust solutions that actually work and actually scale. By providing pipeline automation, self-serve tools, environment management and established practices for observability and compliance, the DevEx team frees developers from the burden of figuring out how to build the pipeline and hook in tools. They can instead focus on what they build: the core product functionality. 'This shift in responsibility is transformative,' enthused Tricentis' Webber. 'When developers aren't forced to create their own 'special flavour' of every operational component, they gain immense speed and agility. They can move faster, knowing that the underlying platform provides reliable, secure and quality-assured foundations.' It appears that the consistency instilled by platform engineering, not just in tools, but in processes and mindset, becomes the bedrock of what this approach means. Webber and others agree that this could be particularly critical in an era where advancements like AI (and the future allure of can rapidly generate code, necessitating robust and consistent guardrails to maintain quality and security. CNCF Overview View 'We're seeing real traction in the CNCF ecosystem where platform engineering, when paired with strong developer experience practices, helps teams improve efficiency and avoid fragmented tooling. The goal isn't rigid standardization; it's creating shared, supported paths that scale with the organization. Especially as AI speeds up engineering development, having consistent, observable and secure platforms in a cloud-native fashion is what keeps innovation sustainable,' said Chris Aniszczyk , CTO, Cloud Native Computing Foundation, a global non-profit dedicated to promoting open computing standards and platforms. Will Fleury, VP of engineering at enterprise AI coding agent company Zencoder sees platform engineering as an opportunity and a challenge. "One squad [developer team], one technology stack each? That's a tax on every software development sprint," he observes. 'The real price of skipping platform engineering isn't the complexity it might add, it's the chaos that fills the gap if we do it wrong. Building and running an internal developer platform takes effort, but letting every squad roll its own infrastructure, compliance hooks and operational plumbing burns far more time, money and ultimately complexity.' Golden Path, Tunnel Vision? It's important to remember that the focus on internal workflows can miss a critical dimension. Platform discussions obsess over shift left (test early) but equally important is what Soham Ganatra , co-founder at Composio calls 'shift out' i.e. when a new service has to handshake with a payments rail or partner API. "If your platform can't make that external connection trivial, developers will tunnel under a paved road and the whole notion of a golden path collapses,' said Ganatra. He saus he has seen teams spend months perfecting internal developer workflows only to watch everything fall apart at the network boundary. 'A beautiful continuous integration and continuous delivery pipeline means nothing if deploying to production requires three Slack messages, two Jira tickets and a phone call to someone in a different timezone just to get firewall rules updated. The platform needs to extend beyond an organization's own chart; it has to anticipate and smooth over the messy realities of partner integrations, compliance audits and the fact that your biggest customer is still running Internet Explorer 11 in production," he said. Shared, standardized, supported software What this whole discussion aims to champion is not DevEx instead of platform engineering, but platform engineering with a crucial developer experience element in it to help avoid the use of isolated or custom-built tools in a shared, standardized and centrally supported ecosystem. For developers following the yellow brick road towards what they hope is elevation to a platform engineering golden path, we need to engineer people, processes and product just as much as we do platform. As the use of AI coding tools deepens across the software industry, it's actually the cultural human workplace factors that will now have an amplified effect on whether software projects succeed or fail.
Forbes
24-06-2025
- Business
- Forbes
How To Build Scalable, Reliable And Effective Internal Tech Systems
In many businesses, platform engineers serve two sets of customers: external clients and internal colleagues. When building tools for internal use, following the same user-centered design principles applied to customer-facing products isn't just good practice—it's a proven way to boost team efficiency, accelerate development and improve overall user satisfaction. Below, members of Forbes Technology Council share key design principles platform engineers should keep front and center whether they're building for clients or colleagues. From prioritizing real team needs to planning ahead for worst-case scenarios, these strategies can ensure internal systems are scalable, reliable and truly supportive of the teams they're built for. 1. Minimize User Friction The one core design principle platform engineers should keep front and center when building internal tools is minimizing user friction by streamlining the journey and improving cycle time. Additionally, internal tools should include clear feedback mechanisms to help users quickly identify and resolve issues, along with just-in-time guidance to support user education as needed. - Naman Raval 2. Build With External Use In Mind You should always consider the possibility that an internal tool may eventually end up being an external tool. With that in mind, you should try not to couple core logic to internal user information. - David Van Ronk, Bridgehead IT Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify? 3. Design With Empathy It's important to design with empathy. Internal tools should prioritize user experience for the engineers and teams who rely on them. Simple, intuitive interfaces and seamless workflows reduce friction, enhance productivity and encourage adoption—making the tool not just functional, but loved. - Luis Peralta, Parallel Plus, Inc. 4. Focus On Simplicity Ease of use and intuitive design must be front and center when building internal tools. Features that are overly nested or require significant learning time directly impact productivity. This inefficiency can be quantified in terms of human hours multiplied by the number of resources affected, potentially leading to substantial revenue loss, especially for larger organizations. - Hari Sonnenahalli, NTT Data Business Solutions 5. Adopt Domain-Driven Design And A 'Streaming Data First' Approach Platform engineers should prioritize domain-driven design to explore, access and share data seamlessly. As cloud diversification and real-time data pipelines become essential, embracing a 'streaming data first' approach is key. This shift enhances automation, reduces complexity and enables rapid, AI-driven insights across business domains. - Guillaume Aymé, 6. Build Scalable Tools With A Self-Service Model A self-service-based scaled service operating model is critical for the success of an internal tool. Often, engineers take internal stakeholders for granted, not realizing they are their customers—customers whose broader use of an internal tool will make or break their product. Alongside scalable design, it will be equally important to have an organizational change management strategy in place. - Abhi Shimpi 7. Prioritize Cognitive Leverage Platform engineers should prioritize cognitive leverage over just reducing cognitive load. Internal tools should simplify tasks, amplify engineers' thinking and accelerate decision-making by surfacing context, patterns and smart defaults. - Manav Kapoor, Amazon 8. Empower Developers With Low-Dependency Tools The platform engineering team should strive to minimize dependencies on themselves when designing any solutions. It's crucial to empower the development team to use these tools independently and efficiently. - Prasad Banala, Dollar General Corporation 9. Lead With API-Driven Development Platform engineers should prioritize API-driven development over jumping straight into UI when building internal tools. Starting with workflows and backend design helps map data, avoid duplicated requests and reduce long-term tech debt. Though slower up front, this approach creates scalable, reliable tools aligned with actual business processes, not just quick fixes for internal use. - Jae Lee, MBLM 10. Observe Real Workflows Platform engineers should design for the actual job to be done, not just stated feature requests. They should observe how teams work and build tools that streamline those critical paths. The best internal tools solve real workflow bottlenecks, not just surface-level asks from teammates. - Alessa Cross, Ventrilo AI 11. Favor Speed, Flexibility And Usability You have to design like you're building a food truck, not a fine-dining kitchen—fast, flexible and usable by anyone on the move. Internal tools should favor speed over ceremony, with intuitive defaults and minimal setup. If your engineers need a manual just to order fries (or deploy code), you've overdesigned the menu. - Joel Frenette, 12. Ensure Tools Are Clear, Simple And Well-Explained When building internal tools, platform engineers should focus on making them easy and smooth for developers to use. If tools are simple, clear and well-explained, developers can do their work faster and without confusion. This saves time, reduces mistakes and helps the whole team work better. - Jay Krishnan, NAIB IT Consultancy Solutions WLL 13. Embrace User-Centric Design Platform engineers should prioritize user-centric design. They must focus on the needs, workflows and pain points of internal users to create intuitive, efficient tools. This principle ensures adoption, reduces training time and boosts productivity, as tools align with real-world use cases, minimizing friction and maximizing value for developers and teams. - Lori Schafer, Digital Wave Technology 14. Prioritize Developer Experience Internal platforms must prioritize developer experience above all. The best tools feel invisible—engineers use them without friction because interfaces are intuitive, documentation is clear and workflows are streamlined. When developers spend more time fighting your platform than building with it, you've failed your mission. - Anuj Tyagi 15. Bake In Observability Platform engineers should treat internal tools as evolving ecosystems, not static products. A core design principle is observability by default—bake in usage analytics, error tracking and feedback hooks from day one. This ensures tools organically improve over time and are grounded in real-world behavior, not assumptions, creating systems that adapt as teams and needs evolve. - Pawan Anand, Ascendion 16. Leverage Progressive Abstraction Progressive abstraction lets internal platforms scale with developer maturity. Engineers can start with guided, low-friction 'golden paths' for beginners while enabling power users to customize, script or access APIs. This balance avoids tool sprawl, supports growth and keeps platforms inclusive, adaptive and relevant over time. - Anusha Nerella, State Street Corporation 17. Streamline Processes Through Predictable, Intuitive Interfaces Internal tools must streamline processes instead of creating additional obstacles. Focus on clear, intuitive interfaces; fast onboarding with minimal documentation; and solid default settings that include advanced options for experienced users. Build in observability and self-service support, and strive for consistent, predictable behavior. - Saket Chaudhari, TriNet Inc. 18. Design Easy Authentication And Authorization Systems There should be ease of authentication and authorization. When building internal tools, you shouldn't design in silos. You must consider how many clicks it takes for an analyst, mid-call with a client, to launch what they need for troubleshooting. Seamless access, least privilege and contextual authentication aren't just security features—they're reflections of good architecture and thoughtful design. - Santosh Ratna Deepika Addagalla, Trizetto Provider Solutions 19. Engineer For High-Stress, Critical Scenarios A word of advice is to engineer for the worst day, not the average day. Internal tools become critical lifelines during incidents, yet we often design them for sunny-weather scenarios. When a system is melting down at 3 a.m. and the on-call engineer is bleary-eyed, that's when your tool's UX truly matters. Simple interfaces with clear error messages become worth their weight in gold. - Ishaan Agarwal, Square 20. Ensure Users Don't Need Deep Platform Knowledge Design for self-service and extension. Internal tools should empower teams to solve problems without deep platform knowledge. Engineers should hide complexity behind sensible defaults and include clean abstractions that allow extensions and clear documentation. Platforms succeed when others can build confidently without needing to ask for help every time. - Abhishek Shivanna, Nubank
