Every project I’ve worked on that went over budget had one thing in common: the people paying for it thought they understood what they were buying. They had a quote, a timeline, and a feature list. What they didn’t have was a real picture of what drives cost in software development. And that gap is expensive. 

I’ve seen a six-figure project balloon because nobody mapped the third-party integrations before kickoff. I’ve seen a “simple” admin panel turn into a three-month ordeal because the access control requirements weren’t defined until week five. That’s exactly what can happen with your project if your cost planning stays surface-level. 

According to Radixweb, a software development company, project costs typically range from US$15,000 to over US$100,000, with the final number shaped by complexity, feature scope, tech stack, and integration requirements. That range exists because software cost isn’t a fixed thing; it’s the sum of hundreds of decisions, many of which get made casually and early. 

Here’s what actually moves the needle. 

The core factors that shape your development budget

Scope: where budgets go to die

Scope isn’t just a list of features. It’s the depth of each feature, the edge cases each one has to handle, and the integrations each one touches. A login screen is a login screen, until it needs MFA, social logins, SSO for enterprise clients, and role-based permissions. Now it’s a two-week job. 

What makes this dangerous isn’t that requirements grow. It’s that they grow quietly. A stakeholder adds something in a meeting. A developer makes an assumption. A “small change” gets absorbed without a conversation about what it costs. By the time anyone notices, the timeline has shifted and the budget is already stressed. 

Before any development begins, force a prioritisation conversation. Not “what do we want” but “what do we actually need at launch.” Every feature pushed to v2 is real money saved, and it’s almost always a feature you thought was essential until you asked the hard question. 

Team structure: You’re not just paying for hours

The sticker price of a developer rate is the least interesting cost question here. What actually matters is how your team is structured and how well it functions. 

A misaligned team (where the client, project manager, and developers are working from different assumptions) generates rework. Rework is expensive not just in hours, but in the momentum it kills. I’ve watched projects where the developers were sharp, and the hourly rate was fair, but the communication structure was so poor that the same features got rebuilt two and three times. 

When you’re evaluating a development partner, ask about their discovery and requirements process before you ask about their rate. A team that charges 20 per cent more but does a proper kickoff, documents requirements, and flags risks early will almost always be cheaper by the end. 

Also Read: The agentic shift: Why AI agents are rewriting the rules of ERP software in Singapore and Malaysia

Technology stack: Two costs, not one

People usually think about the tech stack in terms of build cost: what will it take to develop this? But there’s a second cost that hits you later: the operational cost of running what you built. 

Your infrastructure choices, your database architecture, your reliance on third-party APIs — all of which show up on a monthly bill once you’re live. A product built without scalability in mind might run fine at a few hundred users and require an expensive re-architecture at a few thousand. That’s not a hypothetical. It happens regularly, and it’s almost always preventable with the right conversations upfront. 

Pick a stack that has a healthy developer ecosystem (because you’ll need to hire or replace people eventually), that matches the operational demands of your product, and that your team actually knows well. Novelty is rarely worth the cost premium. 

The hidden costs that quietly break budgets

This is where I see the most financial damage, not in the obvious line items, but in the things nobody budgeted for because nobody mentioned them. 

Maintenance isn’t optional, it’s ongoing

The moment your software ships, the clock starts on its upkeep. Dependencies need updates. Security patches need to be applied. Browsers and operating systems change, and your product has to keep up. A rough but reliable rule: budget 15–20 per cent of your initial development cost every year for maintenance. If that number surprises you, the surprise is worse when it arrives unplanned. 

QA gets cut first and costs the most 

When timelines get tight, testing is usually the first thing squeezed. That decision consistently backfires. A bug caught in development costs a fraction of what it costs in production – in developer time, in user trust, and sometimes in legal exposure. A proper QA process isn’t overhead. It’s the thing that protects everything else you spent. 

Also Read: AI skills now translate into real pay gains for software engineers, NodeFlair finds

Integrations are underestimated almost universally 

Connecting your software to a CRM, payment gateway, ERP, or analytics platform takes longer than anyone expects, tests in ways that are genuinely hard to predict, and creates dependencies you’ll be maintaining forever. The more integrations your product needs, the more you should buffer your timeline and budget — not by 10 per cent, but meaningfully. 

Compliance is a technical cost, not just a legal one 

If your product touches personal data, health records, or financial information, frameworks like GDPR, HIPAA, or PCI DSS require specific technical controls. These aren’t checkboxes but features that need to be designed and built. According to the IBM Cost of a Data Breach Report, organisations that build security in from the start see significantly lower breach costs than those that treat it as a post-launch consideration. Retrofitting compliance after the fact is one of the most expensive things you can do in software. 

The decisions made in week one cost the most

Here’s the thing I wish more clients understood before we started working together: the most expensive part of building software isn’t the development. It’s features built on unclear requirements, architecture chosen for speed instead of longevity, integrations discovered after the fact, and bugs shipped because testing got cut. 

Every major cost overrun I’ve been close to was traceable to something that happened (or didn’t happen!) in the first two weeks. The practical answer is a real discovery phase. Before coding starts, map your requirements in detail, identify your integration points, flag your technical risks, and define what “done” actually means for each feature. It feels like slowing down. It’s actually the fastest path to a product that comes in on budget, because it’s the only way to know what you’re actually building before you’re paying to build it. 

Software development costs are not arbitrary. They are the accumulated result of decisions, some deliberate, many not. Get serious about the decisions, and the costs take care of themselves. 

—

Editor’s note: e27 aims to foster thought leadership by publishing views from the community. You can also share your perspective by submitting an article, video, podcast, or infographic.

The views expressed in this article are those of the author and do not necessarily reflect the official policy or position of e27.

Join us on WhatsApp, Instagram, Facebook, X, and LinkedIn to stay connected.

The post What actually drives software development costs (and why most budgets get it wrong) appeared first on e27.

CME Group recently announced plans to launch Compute Futures, tied to GPU and AI compute capacity. At first glance, this feels counterintuitive. Compute is a technology-driven input where costs consistently decline over time due to hardware improvements, manufacturing scale, and efficiency gains. If the long-run direction is structurally downward, what is there to hedge or price in a futures market?

The key misunderstanding is assuming futures markets exist to express long-term price direction. In reality, they exist to manage short- to medium-term uncertainty, typically within a three- to 24-month horizon, the exact window where real-world capital allocation decisions are made.

This is why even structurally deflationary commodities such as crude oil, natural gas, DRAM, and solar modules still have deep and liquid futures markets. Their long-term cost curves may trend downward, but their short-term prices are driven by highly volatile factors: supply chain disruptions, capacity constraints, inventory cycles, and demand shocks. Market participants are not hedging the fact that something becomes cheaper over decades; they are hedging whether it becomes more expensive or scarce over the next operating cycle.

The same logic applies to compute. For AI labs, hyperscalers, and enterprise users, the relevant risk is not GPU prices in 10 years, but the cost of training runs, inference capacity, and cluster usage in the next quarter or fiscal year. Compute Futures allow these participants to lock in a forward price for compute capacity, converting a variable input cost into a fixed, predictable operating expense.

Also Read: 15 Southeast Asian semiconductor startups moving beyond assembly

This also reflects a structural shift in what compute actually is. Compute is no longer purely a capital good like a CPU or server. It is increasingly a consumable infrastructure service, closer to electricity, airline seats, or hotel rooms. These markets share a critical property: non-storability. An unused GPU-hour cannot be saved for later use, just as an empty hotel room or unsold airline seat has zero value once the time window passes.

Because of this, even if GPU hardware continues a long-term deflationary trajectory, compute rental prices can still exhibit sharp short-term volatility. The constraints are not just chip prices, but system-level bottlenecks: data centre construction cycles (often 18 to 36 months), power grid availability, cooling infrastructure, and uneven deployment of GPU capacity.

On the demand side, volatility is amplified by AI-specific cycles: model breakthroughs, hyperscaler capex waves, startup funding cycles, and sudden surges in inference demand. These factors create mismatches between supply and demand that can push compute prices sharply higher or lower in short periods, independent of hardware cost trends.

Conclusion

Compute Futures are not a bet against long-term price decline. They are a response to short-term price instability in a rapidly scaling AI infrastructure market. As compute becomes a core production input in the AI economy, financial markets are beginning to treat it less like technology hardware and more like a tradable infrastructure commodity with its own risk management and pricing system.

—

The post Why Compute Futures make sense even in a deflationary market appeared first on e27.

People used to ask AI for help with parts of modern life, like making an email sound less annoyed or explaining a spreadsheet formula without forcing anyone to revisit their relationship with mathematics. Lately, the exchange has become more intimate. The same tools built to summarise, draft and optimise are now being invited into moments of doubt, stress and loneliness.

This shift is global, but Singapore gives us a useful early signal. In my work with individuals and organisations in Singapore, I often see how much emotional load people carry while still functioning. Many keep moving through demanding workdays, family responsibilities and social expectations while privately trying to make sense of what they feel.

AI is starting to enter that private space.

A recent Singapore-based study offers a useful glimpse of how this is already happening. In 2026, researchers explored how foreign domestic workers in Singapore used a large language model chatbot while managing caregiving burden. The findings were cautious, but revealing. Participants described the chatbot as emotionally validating, psychologically safe, linguistically accessible, and useful for reassurance and companionship.

For a startup audience, this should raise more than a social welfare eyebrow.

The study points to a wider behaviour change that founders, product teams and employers need to understand. People are beginning to use general-purpose AI tools for emotional processing, especially when human support feels too slow, expensive, risky, or socially complicated. The user may begin by asking for help with a message. Within a few minutes, they may be asking whether their reaction makes sense, how to handle a difficult conversation, or why they feel so depleted.

That is where product design crosses into psychology and the appeal is clear. An AI can respond in plain language, adapt to imperfect phrasing, and give people a feeling of being heard without the social exposure that often comes with disclosure. For people under pressure, that can be powerful.

Also Read: How centralised exchanges swapped crypto ethos for Wall Street fees: Why this will fail

A 2026 cross-cultural study of more than 4,600 participants across seven countries found that people are already using large language models as always-available, non-judgmental confidants for emotional support. The prompts collected in that study showed people seeking help for loneliness, stress, relationship conflict and mental health struggles. This is no longer a fringe use case for companion apps. It is becoming part of ordinary interaction with general-purpose AI.

That shift has real commercial relevance.

If people are using AI tools to manage emotional load, then workplace software, productivity platforms, coaching apps, HR tools and digital health products are already operating closer to mental health territory than many companies may realise. A product designed to help someone draft a message can quickly become a place where they disclose fear, resentment, shame or distress. A tool designed to improve productivity can become the place where an employee admits they are no longer coping.

This creates opportunity, but also responsibility.

Emotionally responsive AI can reduce friction. It can help people name what they are experiencing, organise their thoughts and access support earlier. In a place like Singapore, where people may be managing long hours, family responsibilities, cultural expectations and pressure to remain composed, a low-barrier tool can feel useful. For employers and founders, that usefulness is exactly why the ethical design questions cannot be left until later.

Singapore gives this global shift a sharper local frame. In April 2026, NTU Singapore and NHG Health announced ASPIRE, Singapore’s first work-study training pathway for clinical psychology. The announcement pointed to a clear pressure point: demand for mental health support is rising, while the human workforce takes time to build. That is the gap AI is already moving into.

There is also a trust issue here.

People disclose differently when they believe no human is listening. They may share sensitive details with AI because the interaction feels contained, even when the data environment is more complex than it appears. For companies building emotionally fluent products, privacy cannot sit buried in compliance language. It has to be visible in the user experience. People need to understand what they are sharing, where it goes, how it may be used, and what the tool can do when distress escalates.

Also Read: The death of the traditional org chart: How AI is reshaping work

The most important lesson for startups is that emotional support may appear inside products that were never designed for mental health. A person may stumble into it while drafting a resignation email, preparing for a performance review, translating a difficult message, or trying to make sense of workplace tension. The product team may think they are building a writing assistant. The user may experience it as the first place they can say what they are really feeling.

That is where the next stage of AI design needs more psychological literacy.

Emotionally responsive tools should help people reflect, clarify and access support earlier. They should also make their limits clear. When a user starts disclosing distress, the product needs thoughtful guardrails: clear privacy language, careful emotional tone, referral pathways, escalation options and design choices that encourage agency rather than dependence.

Singapore’s 2026 research gives us an early signal of where this is heading. The study focused on foreign domestic workers using an AI chatbot for caregiving burden, but the lesson reaches further than that setting. People are turning to AI because it is immediate, private and easier to approach than many human systems of support.

For founders and organisations, the takeaway is simple: once a product becomes emotionally useful, it carries emotional responsibility.

AI is no longer only answering prompts. It is becoming part of how people process pressure, uncertainty and loneliness. The companies that understand this early will design tools that earn trust, protect users and know when to guide people back towards human support.

That is the next frontier of AI emotional support. The question is no longer whether people will bring their distress into the interface. They already are. The real design challenge is what the interface does with it.

—

The post Singapore, AI, and the rise of emotional outsourcing appeared first on e27.

The moment we are asked to implement while still experimenting, something within starts to strain.

Lately, I have been noticing this across organisations and teams working through AI integration. There is still a lot of curiosity. New tools, new ideas, new ways of working. At the same time, there is a very real shift happening underneath it.

Conversations are moving from what is possible to what is actually delivering value. The energy has not gone away, but the expectations have changed.

This same pattern has shown up in every major shift in technology

If you look back, the internet followed this exact rhythm. In the early days, it was about presence. Build a website. Try things. See what sticks. Over time, that shifted to performance. E-commerce, conversion, measurable outcomes.

Social media followed a similar path. Brands experimented with voice, content, and engagement. There was freedom in not knowing what would work. Then the shift came. Metrics tightened. Budgets followed performance. Creativity gave way to accountability.

SaaS created another version of this cycle. Organisations adopted tools quickly, often faster than they could integrate them. Over time, the conversation changed from access to utilisation. Are we actually using what we are paying for? Are these tools driving efficiency or just adding complexity?

Cloud was no different. The early push was migration. Move everything. Modernise. Then came the next phase. Cost control. Optimisation. Making sure the investment delivered real operational value.

Also Read: The death of the traditional org chart: How AI is reshaping work

AI is following the same pattern, just at a faster pace

There is a period of expansion where experimentation takes the lead. Organisations explore, build, and test what could work. Over time, that expansion gives way to compression, where the focus turns to implementation, execution, and scale.

The goal is no longer discovery, it is impact.

When organisations move on from experimentation before fully implementing, they leave value on the table and dilute the return on their investment. Right now, many organisations are sitting in between those two states, and in professional services, this tension is even more pronounced.

The people who would benefit most from the efficiency AI can create are often the ones with the least amount of time to engage with it. They are delivering, managing clients, and keeping momentum. Their days are already full. Adding new tools and new ways of working on top of that does not create transformation. It creates strain.

There is also a mismatch happening with clients. Expectations for delivery remain high, often unchanged, while internal teams are being asked to rethink how the work gets done. That gap creates pressure that does not always get acknowledged.

At the same time, we are seeing more adoption happening at senior levels of organisations because they have more space to step back and engage with what is new. They have the ability to explore, test, and think more broadly about applications.

That creates a gap between where AI is being explored and where it actually needs to be implemented.

Junior teams, the ones closest to execution, are often operating in a different reality. They are focused on output, timelines, and immediate deliverables. Without space to experiment, the tools never fully integrate into how the work gets done.

This is where organisations begin to stall

Leadership is pushing for results. Teams are trying to keep up with existing demands. The shift from experimentation to implementation gets stuck in the middle.

There is a natural rhythm at play between expansion and compression. Expansion thrives on curiosity and openness. It invites exploration and new thinking. Compression requires focus, clarity, and space to execute. It demands prioritisation and discipline.

Both are necessary. But they cannot be forced to happen at the same time in the same way.

Also Read: The AI layoff trap points straight at Southeast Asia

As leaders, our role is to recognise where we are in that cycle

Not where we want to be or where the market says we should be, but where we actually are in how our teams operate and what they’re being asked to deliver.

Three reflections for leaders navigating this shift:

• Define where value should show up: Not every experiment needs to scale. Be clear on where implementation matters most and focus your energy there. This creates direction in a moment that can easily feel scattered.
• Create space for change to take hold: If teams are fully consumed by delivery, new ways of working will not stick. Capacity is part of the work. This might mean some hard conversations with clients to reset expectations or reallocate effort.
• Support the shift in how work gets done: Tools alone won’t change outcomes. Adoption requires new habits, new expectations, and time to integrate both. Without that, the tools remain separate from the work instead of improving it.

The movement between expansion and compression is constant. It does not stop with one wave of technology, and it does not resolve all at once. Each new cycle brings the same opportunity and the same risk.

Recognising where you are within it and adjusting how you lead accordingly is what allows progress to take hold in a way that lasts.

This article was co-written with TJ Kelly, a senior partner at Penta Group.

—

Editor’s note: e27 aims to foster thought leadership by publishing views from the community. You can also share your perspective by submitting an article, video, podcast, or infographic.

The views expressed in this article are those of the author and do not necessarily reflect the official policy or position of e27.

Join us on WhatsApp, Instagram, Facebook, X, and LinkedIn to stay connected.

The post The accordion effect: How AI follows the rhythm of expansion and compression appeared first on e27.

The post The Independence Day crypto puzzle: Up or down? appeared first on e27.