DEV Community: Manny Frank

Can Spec-Driven Development Make AI-Generated Code More Reliable?

Manny Frank — Tue, 15 Sep 2026 11:03:03 +0000

AI coding tools can produce code quickly, but speed does not solve unclear requirements. If an AI agent receives incomplete context, it may simply build the wrong feature faster.

AntFlow AI approaches this problem through spec-driven development. It connects business intent, structured requirements, technical specifications, task planning, multi-agent implementation, independent verification, and repository delivery in one workflow.

Instead of asking one AI agent to generate and approve its own work, AntFlow AI separates the process. Builder agents implement tasks, while a verifier agent reviews the output before it reaches a human-controlled approval stage.

Where could this approach be useful?

Building an MVP when requirements are still evolving
Breaking complex features into smaller, testable tasks
Modernizing legacy applications without losing business context
Reducing rework caused by misunderstood requirements
Reviewing AI-generated code before merging it
Coordinating development across existing GitHub or GitLab repositories
Maintaining traceability in security-sensitive projects

The platform is not positioned as a replacement for developers. Human teams still review requirements, approve important decisions, handle exceptions, and control final delivery.

The interesting question is whether defining better specifications before implementation can make AI-assisted development more predictable without adding unnecessary documentation.

Would your team trust AI-generated code more if every change could be traced back to an approved specification and independently verified before merging?

Building PCI DSS-Ready AI Finance Products: What Changes When a Chatbot Touches Payments

Manny Frank — Tue, 15 Sep 2026 05:53:42 +0000

AI chatbots in finance are moving well beyond answering account FAQs.

They can retrieve financial information, assist with disputes, support loan workflows, help with payments, and increasingly interact with systems that can trigger real transactions.

That changes the engineering problem.

A chatbot that only answers questions can operate within a relatively controlled environment. A chatbot that can access payment information or influence a transaction becomes part of a much larger security and compliance surface.

A recent analysis of PCI DSS-ready AI finance products explores this transition, particularly the architecture decisions required when AI, payment systems and financial data meet in the same product.

The interesting part isn't simply making an AI chatbot "PCI compliant."

It's designing the system so the AI doesn't need to handle sensitive payment data in the first place.

The Real Problem With AI Finance Chatbots

Financial institutions have used machine learning for years in areas such as fraud detection, credit scoring and risk management.

Generative AI changes the interface.

Instead of navigating several screens, a customer can ask:

"Why was my payment declined?"

Or:

"Can you help me dispute this transaction?"

Or:

"Can I make this payment now?"

The interface becomes conversational, but the underlying workflow remains complicated.

The chatbot may need to interact with:

Customer identity systems
Core banking platforms
Payment gateways
Fraud detection systems
CRM platforms
Account databases
Knowledge bases
Compliance systems
Human support teams

The AI model is therefore only one component in the architecture.

The real challenge is controlling what happens between the user's message and the final transaction.

When Does a Finance Chatbot Enter PCI DSS Scope?

This is one of the first questions teams should answer during architecture planning.

A chatbot becomes relevant to PCI DSS when it can access, store, transmit or influence systems handling cardholder data. That can include the chat interface, backend services, logs, payment integrations and related infrastructure.

The original analysis highlights an important architectural principle: the model should ideally never receive raw card data.

That means things like PANs, CVVs and PINs shouldn't be passed into prompts, stored in conversation histories or accidentally captured by debugging logs.

Instead, sensitive payment operations should be separated from the conversational layer.

That distinction can dramatically reduce the compliance surface.

A Safer Architecture

A production finance chatbot can be thought of as several controlled layers rather than one giant AI application.

1. Authentication and Access

The user should be authenticated before the system exposes account-specific information.

Short-lived sessions, appropriate authentication controls and inactivity timeouts help reduce the risk of unauthorized access.

2. Input Filtering

User messages should pass through a filtering layer before reaching the model.

This layer can:

Detect payment card information
Mask sensitive fields
Block prohibited data
Identify suspicious input
Prevent sensitive information from reaching prompts

This is particularly important because users don't necessarily understand which information should or shouldn't be entered into a chatbot.

3. AI Orchestration

The orchestration layer determines what the model actually needs.

A user might ask:

"What's my latest transaction?"

The model doesn't necessarily need the user's complete financial record.

The system can retrieve only the relevant information, transform it into an appropriate representation and provide that limited context to the model.

This is where RAG becomes useful.

RAG vs Fine-Tuning for Financial AI

For finance applications, teams often have to decide whether information should live in a retrieval system or be incorporated into model weights.

Area	RAG	Fine-tuning
Data freshness	Easier to update	Requires retraining
Auditability	Easier to trace to source	Harder to trace
Policy updates	Can update knowledge source	May require retraining
Sensitive data exposure	Can remain outside model	Data may become embedded
Governance	Controls can be applied at retrieval	Requires model-level controls
Correction	Remove or update source	Model may retain learned behavior

For frequently changing financial policies and controlled knowledge bases, RAG can provide a more manageable starting point.

It also makes it easier to identify where a response came from.

That doesn't make RAG automatically secure, though.

The retrieval layer itself needs access controls, data filtering and testing against unauthorized retrieval.

4. Guardrails Before Actions

Generating an answer is one thing.

Triggering an action is another.

Imagine a user says:

"Transfer $5,000 to the account I used last month."

A language model shouldn't simply interpret that sentence and execute a transaction.

The system needs policy checks.

The guardrail layer can determine:

Is the user authorized?
Is this transaction permitted?
Does the amount exceed a threshold?
Does this require additional authentication?
Should a human approve it?
Does the request look anomalous?
Is the destination account allowed?

High-risk actions can then be routed to human approval.

This creates an important distinction between AI-assisted workflows and AI-controlled workflows.

For financial systems, keeping that boundary explicit is often more valuable than trying to maximize model autonomy.

5. Keep Payment Processing Outside the Chatbot

One of the strongest architectural patterns is payment gateway isolation.

Instead of allowing the chatbot to collect and process card information directly, the conversational interface can hand the user over to a secure payment component.

For example:

Chatbot → Payment intent → Secure payment page → Payment gateway → Confirmation → Chatbot

The chatbot can know that a payment was completed without ever seeing the underlying card information.

Tokenization can provide another layer of separation.

The system works with a token while the actual card information remains inside the appropriate payment infrastructure.

This approach can reduce the number of components exposed to cardholder data.

6. Don't Forget the Logs

This is an easy place to create an accidental security problem.

Developers frequently log requests while debugging an AI application.

But if a user's message contains payment information, that message could end up in:

Application logs
Error logs
Analytics platforms
Tracing systems
Prompt-management tools
Conversation databases

A system can therefore be secure at the payment gateway while leaking sensitive information through observability tooling.

Production logging should deliberately mask sensitive fields.

Audit trails should still capture enough information to reconstruct what happened without storing unnecessary cardholder data.

AI Governance Is Different From PCI Compliance

PCI DSS addresses payment-card security.

It doesn't solve every problem introduced by AI.

A finance chatbot can still have problems involving:

Prompt injection
Hallucinated financial guidance
Unauthorized tool calls
Insecure retrieval
PII exposure
Model drift
Stale policies
Excessive model permissions
Poor human handoffs

That's why AI governance needs to sit alongside traditional security controls.

For higher-risk workflows, useful controls include:

Model versioning → prompt versioning → retrieval controls → tool permissions → human approval → audit logs → monitoring

The goal isn't to make the model perfect.

The goal is to make the surrounding system resilient when the model isn't perfect.

The Production Problem Is Bigger Than the Prototype

A prototype might successfully demonstrate:

User asks a question → AI responds.

A production system needs to handle:

User authenticates → request is filtered → relevant context is retrieved → AI generates an output → policies evaluate it → tools are authorized → payment systems execute → transaction is logged → monitoring checks the workflow → user receives confirmation.

Every additional step creates another possible failure point.

Common production problems include:

PCI scope expanding unexpectedly
Payment APIs failing under load
Sandbox and production environments sharing access
Incomplete audit trails
Sensitive information entering logs
Slow responses caused by multiple security checks
Poor handoff from chatbot to human support
Third-party vendors with unclear data handling
AI-generated responses becoming inconsistent
Increasing inference and infrastructure costs

This is why compliance shouldn't be treated as a final checklist before launch.

The architecture needs to account for it from the beginning.

Companies Working on AI, Payments and Financial Infrastructure

Several companies are approaching this problem from different directions. They aren't identical competitors, but their work illustrates where the market is heading.

GeekyAnts

GeekyAnts has also explored the engineering requirements behind PCI DSS-ready AI finance products.

The company's recent analysis focuses on the boundary between the AI layer and payment infrastructure, including tokenization, input filtering, RAG, guardrails, payment gateway isolation, audit logging and production readiness. The full technical breakdown is available here.

Stripe

Stripe is increasingly combining payments infrastructure with AI-driven fraud detection, authorization optimization and payment experiences.

Its current AI work includes fraud prevention, payment optimization and a payments foundation model trained on large transaction datasets. Stripe also maintains PCI DSS Level 1 certification for its payment infrastructure.

The interesting architectural lesson is the separation between AI-driven decision-making and the underlying payment infrastructure.

AI can optimize a transaction without necessarily exposing raw card information to every component involved in the workflow.

Accenture

Accenture is approaching financial AI from the broader banking-modernization side.

Its recent work around banking modernization emphasizes the relationship between AI, security, legacy infrastructure and composable architectures. It has also explored generative AI applications in commercial payments, including fraud detection, payment-data security and customer interactions.

That matters because many financial institutions aren't starting with a clean architecture.

They have decades of existing systems that AI needs to work with.

Thoughtworks

Thoughtworks has been working on AI applications across banking, payments and fraud prevention.

Its recent work on transaction foundation models is particularly interesting because it treats transaction intelligence as an end-to-end architecture involving data engineering, tokenization, model training, governance and production deployment.

Its work on graph-based fraud detection also demonstrates how AI can be applied to payment networks rather than simply customer-facing chat interfaces.

The useful takeaway isn't a particular chatbot implementation.

It's the architectural principle behind it: keep sensitive payment operations separated from the AI conversation layer wherever possible.

That reduces unnecessary exposure and gives security and compliance teams a clearer boundary to work with.

What a Production Checklist Should Look Like

Before releasing an AI finance chatbot, teams can work through a checklist like this:

Data

Is cardholder data prevented from reaching the model?
Are sensitive fields masked?
Is the retrieval layer free from unnecessary payment data?
Are retention rules defined?

Security

Is authentication enforced before account access?
Are privileged operations protected with stronger controls?
Are secrets stored separately?
Are production and test environments isolated?

AI

Are prompts version controlled?
Is model behavior evaluated regularly?
Are prompt-injection attacks tested?
Can the model trigger tools without approval?

Payments

Is card data handled by an appropriate payment environment?
Are payment gateways isolated from the conversational layer?
Is tokenization being used where appropriate?
Are failed and partial transactions tested?

Governance

Can every important action be traced?
Is human approval required for high-risk operations?
Can the system be stopped or rolled back?
Are third-party providers reviewed?

Operations

Is latency acceptable?
Are failures monitored?
Are logs protected?
Is there a clear incident-response process?

The Most Important Design Decision

The most important decision may happen before the first prompt is written:

What does the AI actually need access to?

If the answer is "everything," the architecture probably needs another look.

A well-designed finance AI system should expose the model to the minimum information and minimum set of actions required to complete its task.

The payment system should remain responsible for payment processing.

The identity system should remain responsible for identity.

The policy layer should remain responsible for authorization.

The AI should coordinate where it adds value without becoming an unrestricted gateway into the financial system.

That separation becomes increasingly important as finance chatbots evolve from answering questions to taking actions.

Final Takeaway

AI is making financial interfaces more conversational, but it is also pushing chatbots closer to the systems that actually move money.

That changes the engineering requirements.

A production-ready AI finance product needs more than a good model. It needs careful data boundaries, payment isolation, authentication, tokenization, retrieval controls, guardrails, auditability, monitoring and human oversight.

The strongest implementations aren't necessarily the ones that give an AI agent the most control.

They're the ones that give it enough control to be useful while keeping sensitive operations inside well-defined boundaries.

For teams building financial AI products, PCI DSS should therefore be treated as an architecture constraint from day one not something to check after the chatbot already works.

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?