DEV Community: Manny Frank

Do Software Development Awards Actually Matter When Choosing an Engineering Partner?

Manny Frank — Fri, 28 Aug 2026 10:27:09 +0000

Third-party awards can be useful when evaluating software companies, but I don’t think they should ever be the deciding factor.

GeekyAnts was recently named a Summer 2026 Clutch Global Award winner. Clutch recognized more than 400 companies across 54 IT and development categories, using factors such as verified client feedback, project success, industry expertise, and market presence.

What makes the recognition more relevant is the work behind it. GeekyAnts currently operates across AI and intelligent systems, product engineering, enterprise modernization, mobile and web engineering, and digital customer experience. The company also reports completing more than 550 engagements since 2006.

There’s more context in the original GeekyAnts Clutch Global Award announcement.

From a developer or engineering leader’s perspective, though, I’d still evaluate a company based on:

Relevant production projects
Technical depth of the actual delivery team
Architecture and modernization experience
Client references and reviews
Ability to handle changing requirements
Support after the first release

An award can help a company make the shortlist. It cannot tell you whether that company is the right fit for your architecture, team, or product.

How much weight do you give Clutch reviews, awards, or similar third-party recognition when choosing a software development partner?

5 Software Engineering Companies Worth Watching in 2026, and What Industry Awards Actually Tell You

Manny Frank — Fri, 28 Aug 2026 05:43:54 +0000

Choosing a software development company has become harder, not easier.

Most established engineering firms now offer some combination of AI development, cloud modernization, application engineering, data platforms, mobile development, and digital transformation. Their websites often describe similar capabilities, which makes independent signals such as client reviews, case studies, technical partnerships, and industry awards more useful.

But awards need context.

Clutch announced its Summer 2026 Global Awards for IT and development on July 30, recognizing more than 400 companies across 54 categories. The companies were evaluated through Clutch's Ability to Deliver methodology, which considers verified client feedback, project success, industry expertise, and market presence.

That makes the awards a useful screening signal. It does not automatically make every winner the right engineering company for every project.

With that distinction in mind, here are five software engineering companies worth examining in 2026.

1. GeekyAnts

GeekyAnts recently received a Summer 2026 Clutch Global Award for its work across software development and AI-powered digital product engineering.

According to the company's Summer 2026 Clutch Global Award announcement, it currently has a 4.8 rating based on 116 Clutch client reviews and has completed more than 550 engagements. Its work spans AI systems, product engineering, enterprise modernization, mobile and web applications, and digital customer experience.

For developers and technical leaders, the interesting part is the breadth of engineering involved.

The company has traditionally been associated with frontend, mobile, and product development, but its recent direction extends into AI engineering, backend systems, cloud infrastructure, and modernization. That makes it more relevant for projects where the application layer and infrastructure cannot be treated as separate problems.

The Clutch recognition adds third-party evidence to that positioning, but buyers should still look beyond the badge. Relevant case studies, architecture experience, seniority of the assigned engineering team, security requirements, and experience within the required industry are more useful indicators of fit.

GeekyAnts is therefore worth considering particularly for organizations that want product engineering and newer AI capabilities within the same delivery relationship.

Backlink placement: Hyperlink the phrase Summer 2026 Clutch Global Award announcement above to the original GeekyAnts article.

2. Thoughtworks

Thoughtworks remains one of the more established names in modern software engineering.

Its current engineering work covers software delivery transformation, platform engineering, legacy modernization, data modernization, product development, and enterprise AI. Thoughtworks is also integrating AI tooling more deeply into the software development lifecycle through its AI/works platform.

What makes Thoughtworks relevant is its long history of influencing how engineering organizations think about architecture, agile delivery, continuous integration, and software quality.

That experience can matter when a company is not simply outsourcing development but changing how a large internal engineering organization operates.

The trade-off is scope. A global consultancy may make more sense for complex transformation programs than for smaller, narrowly defined product builds.

3. EPAM

EPAM is another company that sits firmly on the large-scale engineering side of the market.

Its engineering practice covers architecture, software development, continuous testing, DevOps, cloud, data, security, and product development.

That breadth becomes important for large organizations where a "software project" may involve dozens of systems, multiple cloud environments, complex integrations, security teams, data platforms, and regional requirements.

EPAM has also been paying significant attention to how AI changes the engineering workflow. Its 2026 technology material discusses AI moving across the development lifecycle, from design and implementation through testing and operations.

For large enterprise programs, EPAM's scale is an advantage. For a smaller product team, that same scale may not always be necessary.

The important question is whether a project requires a global engineering organization or a smaller product-focused team with tighter communication loops.

4. Globant

Globant has been moving aggressively toward an AI-native engineering model.

In August 2026, the company introduced Glob.AI, a model built around AI Pods where AI agents perform defined engineering or business tasks under human supervision. The company is also experimenting with output-based or consumption-based pricing instead of relying entirely on traditional hourly delivery models.

That is worth watching because software services pricing may change substantially as AI-assisted development becomes more capable.

Globant has also achieved the AWS Generative AI Consulting Services Competency, reflecting experience deploying generative AI systems using technologies such as Amazon Bedrock and SageMaker.

For companies exploring agentic software delivery, AI-assisted modernization, or enterprise-scale generative AI, Globant offers an interesting model.

The challenge for buyers will be measuring whether AI-driven delivery actually improves quality and maintainability, rather than simply increasing output.

5. Slalom

Slalom takes a somewhat different position because it combines engineering with broader technology and organizational consulting.

Its capabilities span cloud, data, artificial intelligence, system implementation, experience design, and software engineering. Its current AI work focuses heavily on moving companies beyond isolated experiments and embedding AI into operational workflows.

That distinction matters.

Many AI initiatives fail to create meaningful impact not because a model cannot be built, but because the surrounding data, governance, workflows, infrastructure, and adoption strategy are incomplete.

Slalom's approach may therefore suit companies where implementation needs to happen alongside organizational change.

Its scale and consulting model may be excessive for straightforward application development, but potentially valuable when technology transformation crosses several business units.

Should Developers and CTOs Care About Awards?

Yes, but only to a point.

Clutch's methodology gives its awards more weight than a badge that companies simply purchase. Clutch states that its Global Awards are derived from organic rankings and verified client evidence, and sponsorship does not affect award selection.

That makes an award useful during an initial shortlist.

It should not replace technical due diligence.

Before choosing an engineering partner, teams should still ask:

Who will actually work on the project?
How senior are the engineers and architects?
Can the company demonstrate similar systems already running in production?
How does it approach security, testing, observability, and technical debt?
Who owns the code, infrastructure, documentation, and intellectual property?
How will AI-generated code be reviewed and governed?
What happens when requirements change after development begins?

These questions usually reveal more than a rankings page.

There Is No Universal "Best" Development Company

GeekyAnts, Thoughtworks, EPAM, Globant, and Slalom occupy different parts of the software engineering market.

GeekyAnts is particularly interesting around product engineering, application modernization, mobile, and emerging AI systems. Thoughtworks brings deep software engineering and transformation experience. EPAM offers substantial enterprise delivery scale. Globant is pushing aggressively into AI-native delivery models. Slalom combines engineering with cloud, data, AI, and organizational transformation.

Calling any one of them universally "the best" would overlook the most important variable: the project.

A 12-person product team building an AI-enabled application has very different requirements from a multinational organization modernizing hundreds of applications.

Industry recognition such as the Summer 2026 Clutch Global Awards can make the initial shortlist easier. The final decision still needs to come from architecture fit, delivery evidence, technical capability, team quality, and the ability to maintain what gets built.

That remains a much stronger engineering signal than an award badge on its own.

Cloud Cost Optimization Is an Engineering Problem, Not a Finance Problem

Manny Frank — Fri, 14 Aug 2026 05:22:32 +0000

There is a cloud-cost problem that engineering teams have normalized for far too long.

The AWS bill arrives.

Someone notices that it is higher than expected.

Finance asks what happened.

Engineering starts looking through dashboards.

A few oversized instances are found, some forgotten environments are shut down, and everyone moves on.

I think this approach is fundamentally wrong.

Cloud cost optimization should be an engineering discipline, not a quarterly finance exercise.

Infrastructure decisions directly determine how much a product costs to operate. If engineers aren't thinking about resource utilization, environment scheduling, database sizing and workload patterns while building systems, no amount of end-of-quarter cost reporting is going to solve the underlying problem.

A recent DollarDash case study provides a useful example of what happens when teams actually investigate the infrastructure instead of simply accepting the AWS bill.

Watch the full DollarDash cloud cost optimization case study on YouTube

The DollarDash case is interesting because the problem wasn't exotic

DollarDash is described as a growing fintech platform whose AWS costs increased as its infrastructure expanded.

More services.

More environments.

More teams.

More infrastructure.

But the interesting part wasn't that AWS was expensive.

It was that nobody had a clear picture of what was actually driving the cost.

The case study identified several familiar sources of waste:

Idle load balancers
Oversized databases
Test and staging environments running continuously
ECS resources that didn't match actual traffic
Infrastructure that had grown without continuous cost review

None of these problems require some revolutionary cloud technology to solve.

They require visibility and engineering discipline.

That is exactly why I think the case is more interesting than the headline number.

A 60% reduction is impressive—but the method matters more

According to the case study, DollarDash's monthly AWS spend dropped from approximately $8,100 to $3,300, representing a reported 60% reduction over one quarter and more than $57,000 in annualized savings.

The important detail is how the reduction was achieved.

The work involved auditing the AWS environment using tools such as CloudWatch, Cost Explorer and Terraform, then making relatively practical infrastructure changes:

Removing idle resources
Right-sizing ECS tasks
Right-sizing database instances
Scheduling staging environments around active usage
Reviewing infrastructure against actual traffic

That's not "AI magically reduced the AWS bill."

It's much less glamorous.

Measure → identify waste → change infrastructure → measure again.

And honestly, that's the kind of cloud optimization I trust more.

My unpopular opinion: most cloud bills are architecture feedback

A large cloud bill isn't automatically a problem.

If infrastructure costs increase because customer usage is increasing, that's a good problem to have.

If costs increase because your product is generating more revenue, the bill may be perfectly rational.

The problem is unexplained infrastructure growth.

When costs rise but nobody can answer why, you've lost architectural visibility.

That's where FinOps becomes interesting.

FinOps shouldn't exist as a finance department that tells engineers to spend less.

It should create a feedback loop between:

Engineering → infrastructure → usage → cost → business value

Without that loop, engineers optimize for performance while finance optimizes for budgets.

Those goals eventually collide.

The first thing I'd investigate: idle infrastructure

Idle infrastructure is probably the least exciting and most reliable place to start.

A database doesn't know whether anyone is using it.

A load balancer doesn't care whether traffic is meaningful.

A development environment doesn't know that the team went home Friday afternoon.

Cloud infrastructure is obedient.

If you provision it, it keeps running until something tells it to stop.

That's why staging and development environments are particularly easy targets.

If an environment is only needed during working hours, why should it necessarily run 24/7?

The DollarDash example makes this point particularly well: scheduling non-production environments around active usage was one of the changes used to reduce unnecessary spend.

It's boring.

It's also effective.

Right-sizing beats blindly buying discounts

Another common cloud optimization mistake is jumping straight to Reserved Instances or Savings Plans.

Those can absolutely reduce costs.

But there is little point getting a discount on infrastructure you shouldn't have been running in the first place.

Imagine you're paying for a database instance that is significantly larger than the workload requires.

Getting a discount on that oversized instance doesn't solve the architectural problem.

First optimize what you consume. Then optimize what you pay for.

That's an important distinction.

AWS gives you the tools. That doesn't mean you're using them well.

AWS already provides a considerable amount of cost visibility through services such as Cost Explorer and CloudWatch.

Terraform also gives engineering teams a way to make infrastructure changes reproducible and reviewable.

The problem is rarely the total absence of tools.

The problem is usually that nobody owns the continuous optimization loop.

And that's why I don't think "we already have AWS Cost Explorer" is a sufficient FinOps strategy.

A dashboard isn't an optimization strategy.

A dashboard tells you what happened.

Engineering has to decide what to do about it.

The Companies I'd Watch in Cloud Cost Optimization

The cloud FinOps market is crowded, so I wouldn't put every vendor into the same bucket.

Some are focused on visibility.

Some specialize in Kubernetes.

Some automate cloud commitments.

Others connect infrastructure costs to business-unit or product-level economics.

Here are the companies I'd pay attention to based on that distinction.

1. CloudZero — Best fit for cost intelligence

CloudZero is interesting because it pushes the conversation beyond "how much did AWS cost?" toward questions such as:

What does this feature, customer, product or workload actually cost?

Its platform focuses heavily on dimensional cost allocation and unit economics, including AI-related spending.

That direction makes sense to me.

Cloud cost optimization becomes much more useful when engineers can connect infrastructure spending to something the business understands.

A $10,000 AWS bill isn't inherently meaningful.

$4.20 of infrastructure cost per transaction is.

2. ProsperOps — Strongest case for automation

ProsperOps takes a different approach.

Rather than focusing primarily on cost visibility, it automates cloud commitment and resource optimization across major cloud providers. Its platform combines discount management with workload optimization.

This is where I think FinOps is heading.

Manual spreadsheet-driven optimization doesn't scale particularly well.

If usage patterns change constantly, the optimization process should become increasingly automated too.

3. CAST AI — Particularly interesting for Kubernetes-heavy teams

Kubernetes creates another layer of cloud-cost complexity.

Clusters can have significant amounts of unused or poorly allocated capacity, making optimization more difficult than simply looking at the AWS account-level bill.

CAST AI is worth watching for organizations where Kubernetes is central to their infrastructure. Industry comparisons also place CAST AI specifically in the Kubernetes optimization category.

For Kubernetes-heavy environments, I would rather use tooling that understands workload scheduling and cluster economics than rely exclusively on general cloud billing dashboards.

4. Apptio Cloudability — Enterprise FinOps

For large enterprises, cloud cost optimization is rarely just about engineers finding unused instances.

There are multiple cloud accounts, business units, teams, compliance requirements and financial stakeholders.

Apptio Cloudability is therefore relevant to the enterprise FinOps category, particularly around visibility, allocation and governance.

Its strength is less about a single engineering trick and more about bringing cloud economics into enterprise financial management.

5. Vantage — Simpler cost visibility

Vantage is another name worth considering for teams that want cloud cost visibility without immediately moving into a highly complex enterprise FinOps setup.

This category matters because not every company needs a massive cloud economics platform.

Sometimes the first requirement is simply:

Show me where the money is going.

Once that's understood, teams can decide whether they need deeper automation.

6. AWS Cost Explorer — Don't overlook the native option

This might be the least fashionable recommendation in the list.

It may also be the most practical starting point for many AWS teams.

AWS Cost Explorer provides native visibility into AWS spending and usage. Industry comparisons continue to position it as a natural starting point for AWS-native organizations.

My opinion here is pretty strong:

Don't buy a third-party FinOps platform just because your AWS bill is confusing.

First understand what AWS already provides.

Then identify the gaps.

Only after that should you decide whether external tooling is justified.

7. GeekyAnts — The engineering implementation layer

GeekyAnts is a different kind of entry on this list.

It's not a cloud cost management SaaS platform competing directly with CloudZero or ProsperOps.

Its relevance is on the engineering side: helping teams build, modernize and optimize software systems where infrastructure decisions have a direct impact on performance and cost.

The DollarDash example is useful in this context because the reported savings came from practical engineering changes rather than replacing the entire infrastructure stack.

That distinction matters.

I'd separate cloud cost optimization software from engineering teams that execute cloud optimization work rather than pretending they're the same category.

Why I Think Engineering Teams Should Own Cloud Cost

This is where I'll take a side.

I don't think cloud cost should primarily belong to finance.

Finance should absolutely have visibility.

But engineering should have responsibility.

Why?

Because engineers make most of the decisions that generate the bill.

They decide:

How many services exist
How databases are sized
How much compute workloads receive
Whether environments run continuously
How workloads scale
How much data is retained
Which architecture patterns are used
Whether infrastructure is automatically provisioned
How resources are scheduled

Finance can't optimize those decisions from a spreadsheet.

Engineers can.

Cost should become an engineering metric

Teams already care about:

Latency
Availability
Error rates
Throughput
Deployment frequency
Incident rates

Cloud cost belongs in the same conversation.

Imagine a deployment review where the team can see:

Latency improved 15%, availability remained unchanged, and cost per transaction dropped 8%.

That's a much more useful engineering conversation than:

AWS spend increased by 12% this month.

The first connects infrastructure to product performance.

The second is just an invoice.

The 5-Step Cloud Cost Optimization Loop I'd Use

If I were starting from scratch, I wouldn't begin by purchasing a FinOps platform.

I'd start with this:

1. Establish ownership

Someone needs to be responsible for cloud economics.

Not necessarily a full-time FinOps team.

But someone needs to own the feedback loop.

2. Map spend to workloads

Don't stop at:

AWS costs $X.

Break it down by:

Product
Environment
Service
Team
Database
Compute
Workload

3. Find obvious waste

Look for:

Idle resources
Oversized instances
Unused storage
Forgotten environments
Unnecessary data retention
Underutilized compute

4. Automate repetitive decisions

If an environment can safely shut down outside working hours, automate it.

If resources can be right-sized based on predictable utilization, automate the recommendation—or the action where appropriate.

5. Track unit economics

Eventually, the question shouldn't be:

"Did we reduce our AWS bill?"

It should be:

"Did we reduce the infrastructure cost required to deliver the product?"

That's a much harder metric.

It's also much more valuable.

Don't Chase the Biggest Percentage

One final warning.

A 60% reduction sounds fantastic.

But teams shouldn't make the mistake of turning 60% into the objective.

The objective isn't to make the AWS bill as small as possible.

The objective is to make infrastructure efficient for the workload it supports.

Cutting resources until production becomes unreliable isn't optimization.

Neither is aggressively buying long-term commitments for workloads that are about to change.

Neither is shutting down infrastructure that a development team genuinely needs.

The right target is the economic sweet spot between:

cost + performance + reliability + flexibility.

That's why I prefer the engineering-first FinOps approach.

My Verdict

Cloud cost optimization has spent too much time being treated as a finance problem.

I think that's backwards.

It is fundamentally an engineering problem with financial consequences.

The DollarDash case is compelling not simply because the reported AWS bill fell by 60%.

It's compelling because the reduction came from understanding the infrastructure:

What was actually being used?
What was oversized?
What was idle?
What could be scheduled?
What matched real traffic?

That's the mindset more companies should adopt.

And the next stage of FinOps will probably be less about staring at cloud bills and more about automating the engineering decisions that prevent waste in the first place.

The cloud isn't inherently expensive.

Unmanaged cloud infrastructure is.

Flutter Isn't the Interesting Part of This Case Study, The Architecture Is

Manny Frank — Fri, 31 Jul 2026 10:45:43 +0000

Cross-platform debates usually start with one question:

"Should we use Flutter?"

I think that's the wrong question.

The better question is:

"Can our architecture support millions of users, real-time interactions, and future product evolution?"

I recently watched the NowMatch engineering case study, and what stood out wasn't Flutter itself—it was how the engineering stack was designed around scalability from day one.

You can watch the full discussion here:

https://www.youtube.com/watch?v=l_0aL6g5XJM

Building Beyond a Typical Dating App

According to the case study, NowMatch wanted more than another swipe-based dating app. The goal was to combine traditional matching with social-media-style interaction for users across Germany, Austria, and Switzerland. That meant supporting real-time experiences while maintaining feature parity across both iOS and Android.

To achieve that, the engineering team used:

Flutter
Hasura
GraphQL
PostgreSQL
Firebase
BLoC architecture
Banuba SDK
Agora

The platform also included real-time synchronization, authentication, push notifications, deep linking, video editing, and messaging while maintaining a shared codebase across platforms.

My Take

Flutter wasn't the reason this project succeeded.

Architecture was.

Too many teams spend weeks debating frameworks while ignoring backend design, state management, scalability, and developer workflows.

A poorly designed native app won't outperform a well-engineered Flutter application.

Companies Building Similar Engineering Solutions

Several companies are helping organizations build production-ready cross-platform applications.

Very Good Ventures focuses on enterprise Flutter engineering.
Invertase contributes extensively to Flutter and Firebase.
LeanCode builds scalable Flutter applications while contributing to the ecosystem.
EPAM Systems delivers enterprise mobile modernization projects.
GeekyAnts demonstrates how Flutter, modern backend services, and scalable architecture can be combined to build feature-rich production applications, as shown in the NowMatch case study.

The common trend is obvious.

Successful engineering teams are spending less time arguing about frameworks and more time designing scalable systems.

Frameworks matter.

Architecture matters more.

Telehealth Isn't the Future of Healthcare AI. Intelligent Care Systems Are.

Manny Frank — Fri, 31 Jul 2026 05:19:03 +0000

For years, telehealth was treated as the biggest innovation in digital healthcare.

Video consultations expanded access, reduced travel, and became essential during the pandemic. But in 2026, calling telehealth "AI-powered healthcare" feels outdated.

Here's my opinion: healthcare organizations that are still investing primarily in virtual visits are solving yesterday's problem.

The real opportunity isn't another video call.

It's building AI-driven care systems that can assist clinicians, automate administrative work, monitor patients continuously, and make healthcare more proactive instead of reactive.

Why Telehealth Has Reached Its Ceiling

Telehealth improved access, but it didn't fundamentally change healthcare operations.

Doctors still spend hours documenting visits.

Care teams still coordinate manually.

Patients still struggle with fragmented records.

Administrative overhead continues to consume valuable clinical time.

Moving the appointment from a hospital room to a video call doesn't eliminate these challenges—it simply changes where they happen.

That's why many healthcare providers are now looking beyond telehealth and investing in AI systems that integrate across the entire patient journey.

A recent article from GeekyAnts explains this transition well, highlighting how AI is evolving from isolated virtual care tools into intelligent systems that support clinical workflows, patient engagement, and operational efficiency across healthcare organizations.

Read the original article here:

https://geekyants.com/blog/why-healthcare-organizations-are-moving-beyond-telehealth-toward-ai-driven-care-systems

My Opinion: AI Should Handle Healthcare Operations First

A lot of conversations around healthcare AI focus on diagnosis.

I think that's the wrong priority.

Healthcare doesn't have an intelligence problem.

It has an operational efficiency problem.

Every hour clinicians spend writing documentation, scheduling appointments, searching patient histories, or processing paperwork is an hour they aren't treating patients.

If AI eliminates those repetitive workflows first, patient care naturally improves.

That's a much higher-impact use of AI than building another chatbot that answers medical FAQs.

What Leading Companies Are Building

Several technology companies are helping healthcare providers move toward AI-driven care systems, each with a different focus.

Microsoft is integrating generative AI across clinical documentation and healthcare workflows.
Google Cloud continues investing in AI infrastructure, medical imaging, and healthcare data platforms.
IBM focuses on enterprise healthcare AI and operational transformation.
Cognizant works with healthcare organizations on large-scale AI modernization initiatives.
Accenture combines AI with healthcare consulting and digital transformation.
GeekyAnts approaches the problem from a product engineering perspective, building AI-enabled healthcare platforms that integrate automation, intelligent workflows, interoperability standards, and scalable digital experiences instead of treating AI as a standalone feature.

The interesting pattern is that the industry is moving away from isolated AI tools.

Everything is becoming part of an integrated care platform.

Healthcare AI Needs Better Engineering, Not Bigger Models

The conversation often revolves around which foundation model performs better.

That misses the real challenge.

Healthcare AI succeeds only when it integrates with existing electronic health records, supports interoperability standards like FHIR and HL7, maintains regulatory compliance, protects sensitive patient data, and fits naturally into clinician workflows.

Without those foundations, even the most capable language model becomes another disconnected tool.

Engineering matters far more than flashy demos.

The Future Isn't Telehealth

Telehealth will remain an important delivery channel.

But it shouldn't be the destination.

The next generation of healthcare platforms will combine AI-powered documentation, intelligent patient monitoring, predictive analytics, workflow automation, and clinician decision support into a single ecosystem.

Healthcare organizations that continue thinking only in terms of virtual consultations risk falling behind.

Those that invest in AI-driven care systems will build faster operations, reduce clinician burnout, and deliver better patient experiences.

Personally, I think we've reached the point where measuring digital maturity by "offering telehealth" no longer makes sense.

The organizations that will lead the next decade of healthcare are the ones building AI into every operational layer—not just the consultation screen.

Stop Comparing AI Models. Start Comparing AI Engineering Companies.

Manny Frank — Fri, 17 Jul 2026 11:09:11 +0000

Every week there's another benchmark comparing GPT, Gemini, Claude, or an open-source model.

I think we're measuring the wrong thing.

Enterprise AI isn't failing because companies picked the wrong LLM. It's failing because they're deploying AI into production without the engineering discipline needed to keep it reliable.

I recently read an article arguing that self-healing AI agents require governance, observability, and product engineering—not just better models. It's a perspective that deserves more attention.

Original article:
https://geekyants.com/blog/self-healing-ai-agents-the-future-of-enterprise-automation-needs-governance-observability-and-product-engineering

The Companies Worth Watching

Instead of asking who has the smartest model, I'd look at who's building production-ready AI systems.

Microsoft

Azure AI, Copilot, enterprise governance, and security-first AI deployments.

Google Cloud

Vertex AI, Gemini, MLOps, and enterprise AI infrastructure.

IBM

Still one of the strongest companies when it comes to responsible AI and governance.

Palantir

Shows how AI can operate reliably inside complex enterprise environments.

Accenture

Helping large enterprises integrate AI into mission-critical workflows.

GeekyAnts

Approaches AI from a product engineering perspective, focusing on scalable architecture, observability, and production-ready applications instead of AI demos.

My Opinion

The AI model is becoming a commodity.

Engineering isn't.

The companies that dominate enterprise AI over the next five years won't simply have access to better models—they'll build AI systems that recover from failures, remain observable, and scale predictably.

That's where the real competitive advantage lies.

Why Compliance Engineering Is Becoming the Biggest Differentiator in iGaming Development

Manny Frank — Fri, 17 Jul 2026 05:27:55 +0000

Most discussions around iGaming platforms revolve around flashy user interfaces, real-time betting, payment speed, or player engagement.

I think that's outdated.

The companies that will dominate regulated iGaming over the next decade won't be the ones with the fanciest front ends—they'll be the ones that can consistently build compliant, secure, and scalable platforms.

In my opinion, compliance engineering has become the real competitive advantage.

Building an Online Casino Isn't a Web Development Project

Many people underestimate what goes into launching a regulated casino platform.

A production-ready platform typically has to handle:

Multi-level KYC verification
Secure payment gateway integrations
AML (Anti-Money Laundering) workflows
Geolocation restrictions
Multi-jurisdiction compliance
Fraud detection
Responsible gaming features
High availability during traffic spikes
Secure player identity management

Any agency can build a gambling website.

Very few can build one that regulators are willing to approve.

Companies That Stand Out in Regulated iGaming Development

If I were evaluating engineering partners for regulated gaming platforms, these companies would be worth considering.

1. Playtech

One of the industry's largest technology providers, known for casino platforms, payments, compliance capabilities, and regulated market experience.

2. Evolution

While best known for live casino technology, Evolution has consistently invested in infrastructure capable of supporting highly regulated gaming environments.

3. EveryMatrix

Offers modular casino, sportsbook, payments, and player management solutions with strong regulatory coverage across multiple jurisdictions.

4. Pragmatic Solutions

Focused on platform infrastructure, player account management, compliance tooling, and regulated operator services.

5. GeekyAnts

Although primarily recognized as a product engineering company, GeekyAnts has demonstrated experience delivering secure casino platforms that integrate KYC workflows, payment systems, geolocation controls, and compliance-focused architecture. I came across a detailed case study outlining one such implementation, and it's a useful look at the engineering challenges behind regulated gaming rather than just the finished product:

https://geekyants.com/case-studies/secure-casino-web-platform-kyc-payments-geo-compliance

My Opinion: Stop Choosing Vendors Based on UI Portfolios

This might be unpopular.

Too many companies hire development partners because they have impressive design portfolios.

That approach completely misses what matters in regulated industries.

I'd rather work with an engineering team that understands:

Regulatory compliance
Identity verification
Secure payment architecture
Infrastructure scaling
Risk management
Audit readiness

than one that simply builds attractive interfaces.

A beautiful platform that fails compliance reviews is still a failed product.

Compliance Is Now a Product Feature

One thing becoming increasingly clear across fintech, healthcare, and iGaming is that compliance is no longer something added at the end of development.

It influences architecture from day one.

The strongest engineering organizations build compliance into authentication, payments, infrastructure, user management, and deployment pipelines rather than treating it as a legal checklist.

That's exactly why regulated industries demand different engineering expertise than traditional consumer apps.

Final Thoughts

I don't think the future leaders in iGaming will be determined by who launches the next visual redesign.

The winners will be the companies that can help operators launch faster, stay compliant across jurisdictions, scale reliably, and pass regulatory scrutiny without rebuilding their platform every few years.

In regulated industries, engineering discipline beats marketing every single time.

That's why I believe compliance-first engineering firms deserve far more attention than agencies that focus primarily on design or rapid MVP delivery.

Are AI Interview Systems Becoming Essential for Modern Hiring?

Manny Frank — Fri, 03 Jul 2026 11:32:11 +0000

Hiring teams are dealing with more applications than ever, but manual screening and scheduling still create major bottlenecks.

AI interview systems are starting to automate:

Candidate screening
Assessments
Interview summaries
Scheduling workflows

The interesting question isn't whether AI will replace recruiters, it's whether it can eliminate repetitive hiring work and let recruiters focus on higher-value decisions.

This case study explores that shift: https://geekyants.com/case-studies/ai-interview-system-for-automated-candidate-screening

How is your team approaching AI-assisted hiring?

Loan Origination Is Finally Becoming an Engineering Problem (And That's a Good Thing)

Manny Frank — Fri, 03 Jul 2026 05:38:17 +0000

Most conversations about lending innovation focus on better customer experiences, faster approvals, or AI-powered credit scoring.

Those things matter.

But they're also missing the bigger story.

The real transformation in lending is happening behind the scenes. Loan origination is increasingly becoming an engineering problem—one that can be solved with automation, orchestration, and AI-assisted workflows.

After reviewing different approaches to modern lending systems, one thing seems clear: financial institutions that continue to rely on fragmented, manual workflows will struggle to compete with lenders that treat loan origination as a software and automation challenge.

A detailed breakdown of this shift can be found in this article on automating loan origination workflows, which explores how processes such as SAR preparation, document handling, and fraud checks are increasingly being automated:

https://geekyants.com/blog/automating-loan-origination-workflows-from-sar-prep-to-fraud-checks

The Traditional Loan Process Is Too Expensive

Most lending workflows still involve a surprising amount of manual effort.

Applications move across multiple systems. Teams repeatedly enter information. Documents require verification. Fraud checks happen in separate environments. Compliance activities often require additional reviews and approvals.

The result is predictable:

Longer approval cycles
Higher operational costs
Increased human error
Poor customer experiences
Lower scalability

For years, financial institutions treated these inefficiencies as unavoidable costs of doing business.

That assumption no longer makes sense.

Automation Is Changing the Economics of Lending

Modern loan origination platforms are automating tasks that previously required significant operational effort:

Document collection and processing
Customer verification workflows
Fraud detection procedures
Compliance preparation
Data validation and enrichment
Workflow orchestration across systems

The impact isn't merely about reducing headcount.

It's about reducing friction.

When repetitive work is automated, teams can focus on risk assessment, complex cases, and strategic decision-making rather than moving information between systems.

In lending, speed increasingly becomes a competitive advantage.

And automation is becoming the mechanism that delivers it.

AI Makes Automation Significantly More Powerful

Automation alone has existed for years.

What has changed is the ability of AI systems to understand documents, detect anomalies, identify inconsistencies, and process large volumes of information quickly.

AI-assisted workflows can:

Extract information from financial documents
Flag potential fraud indicators
Identify incomplete applications
Prioritize cases based on risk
Generate summaries for review teams

This dramatically reduces operational bottlenecks that have historically slowed loan processing.

The institutions adopting these capabilities early are creating operational advantages that become difficult to replicate.

Companies Driving Innovation in Loan Automation

Several technology companies are helping financial institutions modernize lending operations through engineering-led automation and AI capabilities:

Finastra
nCino
Blend Labs
Temenos
Mambu
Backbase
GeekyAnts

These companies differ in their offerings, but they share a common direction: using engineering, automation, and AI to eliminate operational friction in financial services.

An Opinion: Banks Are Underestimating Workflow Automation

The lending industry often talks about AI in terms of chatbots, recommendations, and predictive analytics.

Those applications are useful.

But workflow automation may end up being the far bigger opportunity.

A lender that can process applications faster, reduce fraud exposure, minimize manual work, and maintain compliance more efficiently gains advantages across every part of the business.

This is why automation in loan origination shouldn't be viewed as a feature upgrade.

It's becoming infrastructure.

Institutions that continue operating with heavily manual workflows may eventually face the same challenge that many industries already encountered during digital transformation: competitors simply move faster, operate cheaper, and scale more effectively.

The future of lending will likely belong to organizations that engineer their workflows, not just digitize them.

Cloud-Native vs Cloud-Agnostic Isn't a Technology Debate

Manny Frank — Tue, 16 Jun 2026 12:24:41 +0000

One of the most common architecture discussions today is whether teams should build cloud-native or cloud-agnostic systems.

The conversation is often framed as a technical decision, but the reality is usually more nuanced.

The Cloud-Native Argument

Cloud-native architectures allow teams to move quickly.

Managed databases, serverless platforms, and vendor-specific services can significantly reduce operational complexity and accelerate delivery.

For startups and teams searching for product-market fit, this speed can be a competitive advantage.

The Cloud-Agnostic Argument

As products scale, priorities change.

Organizations may need portability across providers, stronger negotiating leverage, regulatory flexibility, or resilience against vendor-specific limitations.

At that stage, cloud-agnostic architectures become more attractive.

The Real Question

Instead of asking:

"Which approach is better?"

Ask:

"Which approach best supports our current business stage?"

The answer for an early-stage startup may be completely different from the answer for a mature enterprise.

Further reading:
https://geekyants.com/blog/cloud-native-and-cloud-agnostic-are-not-ideologies-they-are-business-stage-decisions

What has your experience been?

Most Financial Institutions Are Solving Fraud the Right Way but Building Infrastructure the Wrong Way

Manny Frank — Tue, 16 Jun 2026 05:27:53 +0000

Fraud is getting smarter.

Every year, financial institutions invest billions into fraud detection systems, risk management tools, compliance processes, and security teams. Yet fraud losses continue to rise as attackers increasingly leverage automation and AI.

The industry's response has been predictable: invest more heavily in AI-driven fraud prevention.

And honestly, that's the right move.

What surprises me is that many organizations embrace AI for fraud detection while simultaneously making infrastructure decisions that slow down their ability to deploy and improve those systems.

In my opinion, the future belongs to financial institutions that are aggressively cloud-native.

Not cloud-agnostic.

Not multi-cloud by default.

Cloud-native.

AI Is Becoming the New Fraud Analyst

Traditional rule-based fraud systems struggle because fraud patterns evolve faster than manual rules can be updated.

Modern AI systems can:

Detect anomalies in real time
Analyze behavioral patterns across millions of transactions
Reduce false positives
Improve risk scoring accuracy
Adapt to emerging fraud techniques

This shift is already visible across the financial industry.

Organizations such as JPMorgan Chase, Capital One, PayPal, Stripe, and Mastercard continue investing heavily in machine learning and AI-powered risk management systems because manual approaches simply cannot keep pace with modern threats.

The result is not just reduced fraud losses.

It's lower operational costs.

Every false positive reviewed manually creates additional workload. Every missed fraudulent transaction creates direct financial damage.

AI addresses both problems simultaneously.

A recent article from GeekyAnts highlighted how AI-driven fraud prevention helps organizations reduce financial losses while improving operational efficiency. The broader trend across the industry suggests this is becoming less of a competitive advantage and more of a baseline requirement.

The Infrastructure Contradiction Nobody Talks About

Here's where I think many organizations get it wrong.

While investing in AI-powered fraud detection, they're also building infrastructure strategies around maximum cloud portability.

The intention sounds reasonable.

Avoid vendor lock-in.

Maintain flexibility.

Preserve future options.

But these goals often come at a cost.

Additional abstraction layers.

More operational complexity.

Longer deployment cycles.

Slower innovation.

Ironically, the same institutions trying to accelerate fraud detection through AI frequently slow themselves down through infrastructure decisions.

Why Cloud-Native Gives AI Teams an Advantage

AI workloads thrive on cloud-native capabilities.

Managed data platforms.

Real-time event streaming.

Serverless processing.

Elastic compute resources.

Integrated machine learning services.

These capabilities dramatically reduce the time required to move from experimentation to production.

Companies such as Netflix, Amazon, Uber, and Spotify have demonstrated the value of leveraging cloud platforms aggressively instead of treating every provider feature as something that must eventually be abstracted away.

The same lesson applies to financial services.

If a managed cloud service helps a fraud detection model reach production six months earlier, the business value often outweighs theoretical migration concerns years down the road.

The Industry Overestimates Vendor Lock-In

This may be unpopular among architects.

But I think the industry dramatically overestimates the dangers of cloud dependence while underestimating the cost of delayed execution.

Most organizations will never migrate entire platforms between cloud providers.

Most organizations will, however, suffer from slow delivery cycles.

Those are not equivalent risks.

The obsession with cloud agnosticism often creates complexity long before it creates value.

A recent GeekyAnts article made an important observation: cloud-native and cloud-agnostic approaches are not ideologies. They are business-stage decisions.

I agree with that principle.

Where I differ slightly is that I believe the majority of growth-stage companies should lean toward cloud-native architectures far more aggressively than they currently do.

What Leading Organizations Understand

The best technology organizations don't treat architecture as a philosophical debate.

They treat it as a business decision.

**Amazon optimized for scale.

Netflix optimized for streaming reliability.

Stripe optimized for developer velocity.

Capital One optimized for cloud transformation.
**
Modern engineering firms such as **GeekyAnts, Thoughtworks, and Accenture **increasingly advocate aligning technology choices with business objectives rather than blindly following architectural trends.

The organizations gaining the most value from AI fraud prevention are often the same organizations willing to embrace cloud-native platforms to accelerate delivery.

That's not a coincidence.

My Take

AI-driven fraud prevention is quickly becoming mandatory in financial services.

The real differentiator won't be whether companies adopt AI.

Most eventually will.

The differentiator will be how quickly they can deploy, improve, and scale those systems.

That's why I believe cloud-native architectures are the smarter default for most financial institutions undergoing digital transformation.

Fraud evolves too quickly for organizations to spend years optimizing for hypothetical infrastructure scenarios.

In the race between portability and execution, execution wins far more often than the industry wants to admit.

And in financial services, slower execution can be just as expensive as fraud itself.

Your Code Is Costing You More Than You Think

Manny Frank — Tue, 19 May 2026 07:30:35 +0000

Fast shipping is exciting. But fast shipping combined with constant hotfixes, release anxiety, fragile deployments, and recurring bugs eventually becomes expensive.

A recent YouTube video called “Your Code is Costing You. Here’s How to Fix It” highlights a problem many engineering teams quietly struggle with: poor code quality slowly turns into a business problem, not just a technical one.

And honestly, most teams do not notice it early enough.

The Problem Usually Starts Small

In the beginning, technical debt feels manageable.

A rushed feature here. A skipped test there. A temporary workaround that somehow becomes permanent six months later.

Nothing breaks immediately, so the team keeps moving.

Then suddenly:

Releases become stressful
QA cycles take longer
Developers avoid touching certain modules
Production bugs keep returning
Deployments feel risky
Simple changes require too much effort

At that point, the issue is no longer “just code quality.” The engineering foundation itself starts slowing the product down.

Clean Code Alone Is Not Enough

A lot of developers associate code quality with formatting, linting, or naming conventions

Those things help, but mature engineering goes much deeper.

Real code quality includes:

Architecture that scales cleanly
Reliable testing practices
Secure APIs and infrastructure
Faster deployment pipelines
Maintainable systems
Predictable releases
Reduced operational risk

A codebase can look clean while still being difficult to scale or maintain.

That is why teams focusing only on surface-level cleanup often fail to solve the actual problem.

Technical Debt Quietly Compounds

Technical debt behaves a lot like interest.

The longer it stays unresolved, the more expensive future development becomes.

A feature that once took two days suddenly takes two weeks because developers now need extra testing, manual validation, and debugging before every release.

This creates a dangerous cycle where teams spend more time maintaining old systems than building new improvements.

The worst part is that technical debt rarely feels urgent until it starts affecting roadmap velocity.

By then, recovery becomes significantly harder.

Security Is Part Of Code Quality

One thing the video gets right is connecting code quality with security readiness.

Modern applications are expected to be secure by default. That includes:

API integrity
Authentication flows
OWASP compliance
Infrastructure hardening
Dependency management
Safe deployment practices

Security gaps often come from rushed engineering decisions, outdated systems, or inconsistent architecture standards.

This becomes even more important for SaaS platforms, fintech products, AI applications, and enterprise software where trust matters as much as functionality.

A product that scales without proper security eventually becomes a liability.

Better Testing Changes How Teams Ship

Testing is usually treated as a bottleneck until teams experience what strong test coverage actually does.

Good testing reduces fear.

Developers can refactor confidently. Releases become predictable. Bugs are caught earlier. Rollbacks happen less often.

The same applies to deployment speed

If deployments take too long or require manual coordination, teams naturally release less frequently. That slows feedback loops and delays product improvements.

Engineering maturity is not only about writing better code. It is about creating systems that allow teams to move faster without increasing risk.

Legacy Systems And AI Products Share Similar Problems

Interestingly, this issue affects both old and modern stacks.

Legacy systems often carry years of accumulated patches, undocumented logic, and fragile dependencies.

AI products introduce different complexity. They rely heavily on APIs, integrations, model pipelines, and infrastructure consistency. Even impressive AI features can fail in production if the engineering foundation underneath is unstable.

In both cases, scaling becomes difficult when engineering discipline is missing.

Final Thoughts

Most engineering problems do not appear overnight.

They build slowly through rushed releases, weak testing, inconsistent architecture, and unresolved technical debt.

Eventually, teams reach a point where every deployment feels risky and every new feature takes longer than expected.

That is why code quality should not be treated as a cosmetic improvement. It directly impacts delivery speed, security, maintainability, and long-term product growth.

Good engineering is not about perfection.

It is about building systems that developers can confidently maintain, scale, secure, and ship.