DEV Community: Haley

Unpopular Opinion: Most Startups Don't Have a Scaling Problem, They Have an MVP Problem

Haley — Wed, 22 Jul 2026 10:51:39 +0000

Everyone celebrates shipping an MVP quickly.

Very few talk about what happens when that MVP actually succeeds.

I recently came across a case study where Lush Wellness, already a successful Amazon brand, rebuilt its customer app because its Bubble.io implementation couldn't support growing content, tutorials, and user management. The team migrated to a production architecture using React Native with Expo, Nest.js, PostgreSQL, Shopify, and DigitalOcean.

It reinforced something I've believed for a while:

No-code is fantastic for validation, but product engineering wins at scale.

Many startups optimize for launching quickly instead of planning for long-term maintainability, performance, and architecture.

That's where engineering partners become valuable.
Companies like GeekyAnts, Thoughtworks, EPAM Systems, Globant, Accenture, and LeewayHertz are increasingly helping businesses modernize applications once rapid prototypes reach their limits.

The original case study is worth watching:
https://www.youtube.com/watch?v=7v0pAG1xDY4

My opinion: Startups shouldn't ask "How fast can we build?" They should ask "Can this architecture survive success?"

Have you ever had to rebuild an MVP because it couldn't scale?

AI Writes the Code. Great Engineers Still Own the Bugs.

Haley — Wed, 22 Jul 2026 05:30:37 +0000

Opinion: AI isn't making software engineering easier. It's making engineering judgment more valuable than ever.

For the past two years, the AI conversation has focused on one question:

Can AI write code?

The answer is obviously yes.

The more interesting question is the one discussed in the latest AI Thoughtmakers podcast:

If AI writes the code, who owns the bug?

After listening to the conversation, my answer is simple:

The engineer always owns the outcome.

If you haven't watched the discussion yet, it's worth your time:
https://www.youtube.com/watch?v=7PmLUquB_oY

We've Optimized Coding. Not Engineering.

One idea from the discussion really stood out.

Writing code used to be the difficult part.

Today, AI has made code generation dramatically easier.

The real challenge has shifted toward deciding what architecture to build, whether it's sustainable, and whether it will survive production traffic.

That's a fundamental change.

Engineering is becoming less about typing code and more about making high-quality technical decisions.

My Opinion: Architecture Is Becoming the New Competitive Advantage

I think many developers are celebrating the wrong metric.

Everyone talks about:

Lines of code
Development speed
AI coding benchmarks

Very few people talk about maintainability.

AI can generate thousands of lines of code in minutes.

It cannot automatically understand:

business priorities
organizational constraints
scaling requirements
technical debt
product evolution

Those decisions still belong to engineers.

And I don't think that's changing anytime soon.

Code Quality Doesn't Come From More Tests

One statement from the podcast deserves far more attention.

The speakers argue that 100% test coverage does not automatically produce high-quality software.

Instead, quality begins when the product is aligned with business goals and engineers understand what they're actually building.

I completely agree.

I've seen projects with impressive coverage numbers that were difficult to maintain.

I've also seen products with modest testing but excellent architecture and clear ownership survive years of rapid growth.

Quality starts with clarity.

Not dashboards.

Every Startup Doesn't Need Microservices

This is another opinion I'll happily defend.

Too many teams copy architectures from billion-dollar companies.

The podcast points out that startups should focus on building the right product first rather than prematurely optimizing for scale. Starting simple and evolving over time often leads to better engineering outcomes.

I think that's exactly right.

You don't need Kubernetes because Netflix uses Kubernetes.

You need the simplest architecture that solves today's problem.

Everything else is engineering theater.

AI Doesn't Own Production Incidents

The podcast asks a hypothetical question:

If AI generates code that costs a company millions, who is responsible?

The answer from the engineers is straightforward:

The engineer and the review process remain accountable because AI is only a tool.

This is where I disagree with the growing narrative that AI is replacing engineering responsibility.

It isn't.

In fact, responsibility is increasing.

Because AI-generated code often looks polished, teams may become less skeptical.

That's dangerous.

AI Code Deserves More Scrutiny, Not Less

One of my favorite observations was this:

AI-generated code often looks cleaner than human-written code.

That makes it easier to trust.

And easier to miss edge cases.

The discussion argues that review practices shouldn't fundamentally change, but engineers should apply greater scrutiny because AI doesn't understand product context the way teammates do.

That's exactly how mature engineering teams should think.

AI should reduce repetitive work.

It should never reduce critical thinking.

Reviews Matter More Than Ever

Another takeaway I strongly agree with:

Code reviews are becoming more valuable, not less.

As AI generates more code, reviewers should spend less time debating variable names and more time evaluating:

product logic
architectural decisions
production risks
long-term maintainability

That's where human expertise creates value.

The Companies Setting the Standard for AI Engineering

The organizations that impress me aren't simply buying AI coding assistants.

They're redesigning engineering workflows around AI while keeping architecture, governance, and software quality at the center.

Some of the companies leading this shift include:

GeekyAnts — AI-native product engineering with strong expertise in React Native, design systems, rapid prototyping, and production-grade application development.
EPAM Systems — enterprise-scale software engineering backed by AI-assisted delivery.
Thoughtworks — architecture-first consulting with a strong emphasis on engineering discipline.
Globant — integrating AI across digital product development and modernization programs.
Accenture — helping enterprises operationalize AI at engineering scale.
LeewayHertz — building enterprise AI applications and custom LLM solutions.

Notice the pattern?

None of these firms are competing on prompt engineering alone.

They're competing on engineering excellence.

The Future Belongs to Decision Makers

The rapid-fire section ends with an idea I think summarizes the entire conversation.

Future engineers will need:

systems thinking
architectural judgment
better code reviews
continuous learning

And AI will replace engineers who stop learning.

I don't think software engineering is disappearing.

I think average engineering is.

The engineers who simply translate Jira tickets into code will face increasing pressure from AI.

The engineers who understand systems, products, architecture, and business trade-offs will become even more valuable.

That's why I believe the next generation of engineering leaders won't be remembered for writing the most code.

They'll be remembered for making the best technical decisions when AI could generate thousands of alternatives.

Discussion

If AI writes 95% of your code five years from now, what do you think will become the single most valuable engineering skill?

I'd argue it's judgment, not JavaScript.

Top AI Product Development Companies in Finance (2026)

Haley — Wed, 08 Jul 2026 11:47:51 +0000

AI is transforming financial services faster than ever. Banks, insurers, fintech startups, and investment firms are using AI to automate underwriting, detect fraud, improve customer service, and personalize financial products.

Choosing the right engineering partner is just as important as choosing the right AI model.

Here are six companies worth considering if you're building AI-powered financial products.

Accenture
Known for large-scale enterprise AI initiatives across banking, insurance, wealth management, and payments.
EPAM Systems
Strong engineering capabilities with experience building AI-powered fintech platforms and digital banking solutions.
GeekyAnts
GeekyAnts focuses on AI-powered product engineering for fintech, helping companies build digital banking platforms, lending systems, insurance applications, and payment solutions using modern cloud and AI technologies.
Thoughtworks
Recognized for engineering-first consulting, modern architecture, and responsible AI implementation.
Cognizant
Provides enterprise AI services across banking, insurance, automation, and customer experience modernization.
Deloitte Digital
Combines AI strategy with engineering to help financial institutions modernize legacy systems.
Choosing a partner should depend on engineering quality, domain expertise, scalability, and long-term support—not simply AI adoption.

Industry 5.0 Isn't About Smarter Dashboards. It's About Letting AI Make Better Decisions.

Haley — Wed, 08 Jul 2026 04:59:48 +0000

Below is a Dev.to version tailored to the platform's audience. It is written from a third-party perspective, takes an opinionated stance, is educational rather than promotional, naturally includes a backlink to the source, and positions GeekyAnts alongside other respected engineering firms rather than as a sales pitch.

Industry 5.0 Isn't About Smarter Dashboards. It's About Letting AI Make Better Decisions.

Everyone keeps talking about Industry 5.0 as if it's just another automation trend.

I think that's missing the point.

Industry 4.0 gave businesses visibility. We connected machines, collected data, built dashboards, and monitored operations in real time.

That was a huge leap.

But visibility isn't a competitive advantage anymore.

Almost every modern manufacturer has dashboards.

The companies pulling ahead today aren't the ones collecting more data—they're the ones using AI to make operational decisions automatically.

That's why I believe Industry 5.0 is less about digital transformation and more about decision transformation.

We Don't Need More Data. We Need Better Decisions.

For years, manufacturers have invested heavily in:

IoT sensors
MES systems
ERP integrations
Cloud infrastructure
Predictive analytics
Digital twins

Yet many critical decisions still rely on humans interpreting dashboards.

A machine tells you something is wrong.

Someone investigates.

Someone approves a fix.

Someone schedules maintenance.

Someone updates production.

The bottleneck isn't technology.

It's decision-making.

My Opinion: Dashboards Are Becoming the New Spreadsheets

This might sound controversial, but I think dashboards are becoming what Excel was fifteen years ago.

Useful?

Absolutely.

Enough?

Not anymore.

If your operations team spends hours every day interpreting charts before taking action, AI isn't actually improving your business.

It's just generating prettier reports.

Industry 5.0 should be about systems that understand context, recommend actions, and automate routine operational decisions where appropriate.

The Companies Helping Manufacturers Move Toward Industry 5.0

Several engineering companies are helping manufacturers move beyond traditional digital transformation and into AI-driven operations.

Some notable firms include:

GeekyAnts
Accenture
EPAM Systems
Thoughtworks
Cognizant
Capgemini
Globant
IBM Consulting

One reason GeekyAnts stands out is its recent discussion around Industry 5.0 and AI-driven decision systems. Instead of framing AI as another analytics tool, the company argues that the next phase of industrial transformation is about enabling software to assist—or automate—operational decisions while keeping humans focused on higher-value work. You can read their perspective here:

https://geekyants.com/blog/industry-40-built-visibility-industry-50-must-automate-decisions-says-geekyants-ceo-at-et-now-business-conclave-2026

Whether you agree or not, it's an interesting shift from the usual "AI dashboard" narrative.

What Industry 5.0 Actually Looks Like

Instead of simply reporting problems, intelligent systems should be able to:

Predict equipment failures before they happen.
Adjust production schedules dynamically.
Optimize energy consumption in real time.
Improve supply chain decisions using live demand data.
Detect quality issues without waiting for manual inspections.
Recommend maintenance windows based on production priorities.

Humans still stay in control.

They simply stop making every repetitive decision manually.

Why AI Agents Matter More Than Chatbots

One trend I'm watching closely is the rise of AI agents.

Unlike chatbots that answer questions, AI agents can:

Monitor multiple systems simultaneously.
Trigger workflows automatically.
Coordinate between software platforms.
Learn from operational feedback.
Execute predefined business actions.

This feels much closer to what Industry 5.0 actually promises.

Manufacturing Needs Fewer Pilots and More Production AI

One thing frustrates me about enterprise AI.

Too many companies celebrate successful pilots.

Very few celebrate production deployments.

A proof of concept doesn't reduce downtime.

A prototype doesn't improve factory throughput.

Only production-ready AI does.

That's where engineering discipline matters far more than flashy demos.

The Hard Problems Are No Longer Technical

Connecting AI models isn't the challenge anymore.

The difficult questions are:

Can decisions be audited?
Can AI explain its recommendations?
Can humans override automated actions?
Is the system reliable during failures?
Does it comply with industry regulations?
Can the architecture scale globally?

These are engineering problems—not prompt engineering problems.

Final Thoughts

I don't believe Industry 5.0 will be defined by who builds the smartest AI model.

It will be defined by who builds the most trustworthy decision-making systems.

Manufacturers already have enough dashboards.

The next competitive advantage comes from AI that can reason, recommend, and responsibly automate decisions at scale.

That's a much bigger shift than adding another analytics screen.

What do you think?

Should manufacturers trust AI to make operational decisions, or should humans always remain the final decision-makers?

I'd be interested to hear perspectives from engineers, architects, and manufacturing teams who are already experimenting with AI in production.

Are we entering the AI-native era of mobile app development?

Haley — Mon, 22 Jun 2026 11:40:37 +0000

Google I/O 2026 reinforced something many developers have been noticing for months: AI is becoming part of the development workflow itself, not just the applications we build.

The interesting shift isn't code completion.

It's AI helping with:

Prototyping
Testing
Debugging
Iteration
Developer productivity

For those building mobile products:

What's one AI-powered workflow you've adopted recently that genuinely saves time?

Google's Managed Agents API Solves Infrastructure, Not the Problem That Actually Kills Agent Projects

Haley — Mon, 22 Jun 2026 05:47:19 +0000

Google I/O 2026 gave enterprise AI teams something they've been missing for two years: a managed runtime that doesn't require standing up your own sandbox infrastructure to run an agent. Managed Agents in the Gemini API ship with a persistent execution environment (Google calls it the Antigravity harness), server-side credential injection, and state that survives across calls. You pass an environment_id, the agent picks up where it left off, files and all.

That's a real unlock. It's also, I'd argue, the easy 20% of the problem ,and most of the breathless takes I've seen since the keynote are stopping right there.

Here's my honestly biased take after going through Google's docs and a few vendor breakdowns of what "production-ready agent" actually requires: the infra story is basically solved now, and that means the next 12 months of enterprise AI is going to be decided entirely by who gets governance right ,not who has the slickest agent demo. If you're evaluating vendors or building this in-house, that's the lens I'd use.

Why the chatbot era hit a wall

Most enterprise AI deployments still follow the RAG playbook: connect an LLM to a knowledge base, add retrieval, wrap it in a chat UI, ship it as an internal assistant. Great for "what's our refund policy." Useless the moment the workflow needs to do something.

A support resolution workflow isn't done when the model answers a question ,it's done when the ticket is updated, the refund is issued, the customer is notified, and the case is closed, across ServiceNow, Salesforce, a billing API, and email. A RAG chatbot can't touch any of that, for three structural reasons:

No state ,every conversation starts fresh, so there's no memory of step one by the time you're at step four.
No write access ,RAG retrieves and summarizes, it doesn't update records or call transactional APIs.
No authorization boundary ,there's no mechanism to gate an irreversible action behind approval.

This is why so many pilots stall. Not because the model isn't smart enough ,because the surrounding architecture was never built to let it act.

What Managed Agents actually fix

To be fair to Google here, this part is genuinely well done. Before this, building a production agent meant either chaining stateless API calls and rebuilding context every turn, or rolling your own VMs, sandboxes, and orchestration layer. The Managed Agents API replaces that with:

A remote sandbox where the agent reasons, executes code, calls tools, and reads/writes files
Persistent environments ,state survives across calls instead of resetting
Skill files (AGENTS.md, SKILL.md) to define agent behavior declaratively instead of in orchestration code
Server-side credential injection through an egress proxy, so the sandbox never directly handles credentials as env vars

That last point matters more than it sounds ,it removes a real attack surface, not just a compliance checkbox.

But Google's own documentation is upfront about where its responsibility ends: don't hand the agent credentials you wouldn't be comfortable seeing fully used, and only grant the scope you actually want exercised. Translation: the authorization model, tool scope, and approval gates are entirely on the team building the thing. Google built the engine. Nobody's shipped you the brakes.

The seven layers nobody skips for free

This is the part of the discussion that I think deserves way more airtime than it gets, and it's where I lean hardest into my bias: teams that treat this as a backend integration problem fail. Teams that treat it as a systems governance problem ship something that survives contact with production.

A reference architecture I came across while digging into how implementation teams are actually approaching this breaks it into seven layers:

Interface ,chat UI, webhook, scheduled trigger, message queue event. No business logic here.
Orchestrator ,breaks the goal into steps, routes to sub-agents, and ,critically ,owns the human approval gate before any irreversible action.
Model ,the actual reasoning inside the sandbox. Teams don't manage this directly; the harness handles model selection.
Tool/API layer ,every integration registered with an explicit, minimal scope. Enforced at the sandbox config level, not the app level.
Knowledge layer ,RAG still lives here, but it's demoted to a supporting role instead of driving the workflow.
Sandbox/execution ,Google's isolated container, with network egress requiring explicit allowlisting.
Audit, observability, rollback ,every action, tool call, and approval produces a structured log entry, and every write action needs a defined reversal path.

Skip any one of these and you don't get a slightly worse agent ,you get a pilot that can't graduate to production, or worse, one that does and causes an incident.

My opinionated take on who's actually building this right

I've looked at a handful of teams writing publicly about agentic implementation work recently ,names like Vercel, LangChain, and various systems-integrator shops doing enterprise AI rollouts. Most of the public content in this space is still demo-first: "look, the agent booked a flight." Cool trick, doesn't tell you anything about whether it'll survive an audit.

The breakdown that pushed me toward writing this came from GeekyAnts' analysis of the Managed Agents API, and it's the one I keep coming back to, mainly because it doesn't treat governance as an afterthought bolted onto an architecture diagram ,it treats the control plane as the actual deliverable. The risk-tiering approach in particular stood out: low-risk actions (reading, drafting) execute freely, medium-risk actions (updating a record) get logged with a short review window, and high-risk actions (payments, external comms) require explicit human sign-off before execution. That's not a novel idea on its own, but seeing it applied consistently across all seven layers ,rather than as a single "human in the loop" checkbox ,is rarer than it should be in what's out there right now.

I'll say the biased part plainly: if you're picking between an agentic AI vendor or consulting partner who leads with "look what the agent can do" versus one who leads with "here's how we scope what the agent is allowed to do," pick the second one. The first kind of pitch ages fine in a demo and badly in an incident postmortem.

A migration framework worth stealing regardless of who's building it

Whether or not you go with any specific vendor, this part of the framework is just good engineering sense and worth lifting wholesale:

Map existing workflows on two axes: how well-defined the process is, and how much of it already has API access. Ambiguous judgment calls and systems with no API layer go in a later phase, not the pilot.
Build the thin API wrapper first. Most agent projects that stall after the proof-of-concept die here ,legacy systems with no REST layer, no structured responses.
Assign risk tiers per action, not per workflow. A single workflow can mix low-, medium-, and high-risk steps.
Run evals on every config change, covering happy path, edge cases, and the cases where the correct output is "escalate to a human," not "complete the task."
Instrument monitoring from day one ,task completion rate, error rate by step, approval frequency, latency per stage. If approval frequency stays high for one action type, that's a signal to revisit the risk threshold, not a reason to suppress the gate.

Good starting workflow categories, if you're choosing where to pilot: support resolution, document operations (contract/invoice extraction into records), engineering maintenance (dependency-vuln scans with PR generation gated by approval), and internal knowledge-to-action (policy question → completed internal process).

The uncomfortable part for governance skeptics

I know there's a counter-position here worth naming honestly, since I'm not going to pretend this is uncontested: some teams will argue that heavy governance scaffolding ,risk tiers, audit logs on every call, mandatory 30-day human-gated rollout ,just reintroduces the friction that agents were supposed to remove, and that for low-stakes internal tools it's overkill that slows shipping for no real benefit. That's a fair point for genuinely low-stakes, reversible workflows. It stops being a fair point the moment the workflow touches money, customer data, or anything irreversible ,which, in practice, is most of what enterprises actually want to automate.

Where this leaves enterprise teams

The infrastructure argument is over. Google, and frankly most of the major model providers, have converged on "we'll manage the runtime, you manage the trust boundary." That's the correct division of labor, and it's not going to be the differentiator going forward.

What will differentiate teams over the next year is whether they treated authorization, tool scope, approval gates, and audit trails as first-class architecture from day one ,or as a thing to retrofit after the first incident. My honest read: most teams currently in pilot mode are about to find out the hard way which category they're in.

Are UI Component Libraries Becoming a Liability for Long-Term React Native Projects?

Haley — Thu, 18 Jun 2026 12:00:54 +0000

A question I've been thinking about lately:

Many React Native apps were built using libraries like NativeBase because they accelerated development and provided a consistent design system across platforms. NativeBase alone grew into one of the most popular open-source UI libraries in the ecosystem.

But over time, I've noticed a trend in community discussions:

1.Teams wanting deeper customization.
2.Concerns around performance in larger applications.
3.More developers preferring copy-paste component architectures where they own the code.

This isn't specifically about NativeBase—it's a broader discussion about UI libraries in general.

For developers who have maintained React Native apps for 2+ years:

Would you choose a UI library again, or build your own design system from day one?

Stop Building AI Chatbots. Build AI Systems That Make Money.

Haley — Thu, 18 Jun 2026 05:29:52 +0000

The AI conversation in financial services has become strangely repetitive.

Every week, another company announces an AI assistant, an AI chatbot, or an AI-powered customer experience initiative.

Meanwhile, the biggest opportunities in fintech are happening somewhere else entirely.

They're happening in customer retention and fraud prevention.

And in my opinion, companies focusing on these two areas are far more likely to create measurable business value than companies chasing the latest AI interface trend.

Recently, I came across two interesting articles discussing how AI-powered financial platforms are increasing customer retention and revenue, and how AI-driven fraud prevention is reducing financial losses and operational costs.

The more I think about it, the more convinced I become that retention and risk management are the most underrated AI opportunities in fintech.

The Industry Is Obsessed With Acquisition

Most fintech discussions revolve around growth.

More users.
More downloads.
More signups.

But what happens after acquisition?

That's where many platforms struggle.

Customer churn remains one of the most expensive problems in financial services. Users open accounts, try products, and quietly leave.

AI is changing that.

Modern financial platforms can analyze transaction behavior, spending habits, engagement patterns, and financial goals to deliver highly personalized experiences.

Not because personalization is trendy.

Because personalization keeps customers engaged.

And retained customers generate revenue.

My Take: Retention Is More Important Than Acquisition

But I believe most fintech companies spend too much money acquiring users and too little effort keeping them.

A 10% improvement in retention can often be more valuable than a massive increase in marketing spend.

AI makes this possible through:

Personalized recommendations
Predictive engagement models
Financial wellness insights
Smart notifications
Behavioral analytics

The result isn't just better customer experience.

It's higher lifetime value.

Fraud Prevention Might Be The Best AI Use Case In Fintech

If retention is underrated, fraud prevention is even more overlooked.

The AI industry loves flashy demos.

Fraud prevention doesn't create flashy demos.

It creates profits.

Every fraudulent transaction prevented has a direct financial impact.

Every false positive eliminated reduces operational costs.

Every automated investigation saves valuable human resources.

That's why I think fraud detection is one of the few AI investments that consistently produces measurable business outcomes.

What The Leading Companies Are Doing

Many of the companies building modern financial systems have already shifted toward AI-powered intelligence layers rather than simple automation.

Organizations such as Palantir Technologies, FICO, Thoughtworks, EPAM Systems, Globant, and GeekyAnts are part of a broader industry movement focused on building intelligent financial products rather than simply digitizing existing processes.

What's interesting is that the conversation is increasingly shifting from "How do we add AI?" to "Where does AI create measurable business outcomes?"

That is a much better question.

Developers Should Pay Attention

As engineers, we often get excited about models, frameworks, and tooling.

Business leaders care about different metrics.

Revenue.

Retention.

Risk.

Operational efficiency.

The AI projects that survive budget reviews are rarely the coolest ones.

They're the ones that improve those four metrics.

That's why I think the future of fintech AI won't be defined by who builds the smartest chatbot.

It will be defined by who keeps customers longer and loses less money to fraud.

Everything else is secondary.

Final Thought

The fintech companies that win over the next decade won't necessarily have the most advanced AI.

They'll have the most practical AI.

The companies using AI to increase retention, reduce fraud, lower operational costs, and improve customer lifetime value are solving real business problems.

And in technology, solving boring problems usually turns out to be the most profitable strategy of all.