DEV Community: Yashas Mahadev

Taking Claude into Production: The Engineering Around the Model

Yashas Mahadev — Tue, 22 Sep 2026 10:26:36 +0000

GeekyAnts has joined the Claude Partner Network as a registered Services Track member, with a certification cohort in progress. Its announcement highlights a practical engineering issue: deploying an AI feature requires decisions across the entire application.

Key takeaways for developers:

Data boundaries: Define which information the model can receive and enforce user permissions.
Evaluation: Test output quality, latency, and failure handling against actual workflows.
Observability: Monitor application behavior and assign responsibility for operational issues.
Human review: Establish escalation paths for uncertain outputs and sensitive actions.

These concerns apply to document processing, customer support, and internal knowledge assistants. The article also describes a multi-model approach involving Claude and GPT, depending on product requirements.

Partner membership provides training and technical resources; application reliability still depends on implementation and testing.

Read the full GeekyAnts announcement.

Which has been the biggest challenge in your AI deployment: permissions, evaluation, or monitoring?

5 Software Development Companies to Evaluate in 2026: What Client Reviews Reveal About Delivery

Yashas Mahadev — Tue, 22 Sep 2026 06:05:00 +0000

A software development partner can deliver a working application and still leave the internal engineering team with difficult maintenance decisions.

The code may meet the original requirements, while documentation remains incomplete. A release may arrive on schedule, while essential testing moves into the next sprint. A reasonable initial estimate may exclude integration work that becomes unavoidable later.

For developers and engineering managers, these details matter when evaluating a partner. Client reviews can help identify questions worth asking, provided the assessment goes beyond the overall star rating.

What the Client Review Analysis Shows

In its September 2026 publication, GeekyAnts’ client review analysis reports a 4.9 overall Clutch rating across 120 verified reviews. Its reported sub-scores are 4.8 for quality, 4.8 for schedule, 4.7 for cost, and 4.9 for willingness to refer.

The company identifies recurring praise for project management, communication across time zones, flexible staffing, and value for cost. It also acknowledges concerns about timeline adherence, scoping around the UI/UX-to-development transition, and initial estimate accuracy.

These findings come from the company’s interpretation of its review record. They provide a starting point for evaluation, rather than an independent comparison of development providers.

The useful lesson is that positive feedback and delivery concerns can coexist. An engineering team needs to understand which conditions produced each outcome.

How Developers Can Turn Reviews Into Technical Questions

A statement such as “communication was excellent” provides limited information about the engineering process. The practical follow-up is whether important decisions remained accessible after the meeting ended.

Similarly, “the team handled changes well” should prompt questions about how changes affected estimates, test coverage, and release commitments.

A review becomes more useful when it leads to a request for evidence:

Review theme	Engineering question	Evidence to request
Clear communication	How are technical decisions recorded?	An anonymized architecture decision record
Predictable delivery	How are dependencies and blockers tracked?	A milestone plan showing dependency owners
Flexible response to changes	How are scope changes assessed?	A sample change-impact assessment
Good software quality	What must pass before a release?	A definition of done and example CI checks
Reasonable pricing	Which assumptions could change the estimate?	An estimate with exclusions and uncertainty ranges

These artifacts help a prospective client assess how the proposed team works. They also make comparisons more concrete than a collection of testimonials.

Five Software Development Companies Worth Comparing

The following shortlist covers companies with documented product engineering or software delivery offerings. It is an editorial selection, not a benchmarked ranking of client satisfaction. Company size, engagement model, and project requirements can materially change the fit.

1. GeekyAnts

GeekyAnts describes its work as AI-powered digital product engineering and consulting. Its published review analysis makes delivery practices and acknowledged weaknesses available for scrutiny.

A prospective client could use those disclosures to structure a discovery engagement. The evaluation should establish acceptance criteria, estimate assumptions, and responsibility for resolving design ambiguities before implementation begins.

For developers joining the project, a useful question is whether the proposed team can demonstrate a complete handover: repository access, setup instructions, tests, deployment documentation, and ownership of outstanding issues.

2. Thoughtworks

Thoughtworks’ AI/works offering describes support for new software development and modernization, including specifications, engineering workflows, and governance.

Its published scope makes it relevant to an evaluation involving existing systems whose behavior needs to be understood before changes begin.

An engineering assessment should examine how the proposed team validates undocumented business rules. A modernization plan should explain how existing behavior will be tested, which changes are intentional, and how migration failures will be handled.

3. EPAM

EPAM lists platform and product development, quality engineering, DevOps, API integration, and modernization among its engineering services

Those capabilities provide a basis for considering it when a project spans application development and the surrounding delivery infrastructure.

The practical evaluation should focus on the team assigned to the engagement. Relevant questions include who owns architectural decisions, how specialists coordinate across workstreams, and what knowledge transfers to the client’s engineers throughout delivery.

4. Globant

Globant’s AI Pods describe delivery services covering product discovery, architecture, implementation, testing, and modernization, with experts supervising agent workflows.

For teams considering this model, the unit of delivery deserves close attention. A generated specification, completed feature, and production release represent different outcomes.

Acceptance criteria should specify the expected tests, documentation, review process, and correction responsibilities. A pilot should measure how much work the internal team must perform before accepting the output.

5. GlobalLogic

GlobalLogic’s VelocityAI approach includes AI-assisted software development and emphasizes adapting engineering workflows to organizational needs.

It provides another option for organizations comparing how AI can fit into an established product development process.

A technical evaluation should examine a representative change in an existing application. The assessment should include integration effort, regression testing, observability, and maintenance, alongside the time spent implementing the feature.

A Small Delivery Exercise Can Make the Comparison Clearer

After reviewing references, an organization can ask shortlisted partners to propose a bounded delivery exercise.

A hypothetical example is adding role-based access to an existing administrative interface. Even a small change can expose important engineering decisions: where authorization runs, how permissions are tested, what happens to existing users, and how failures appear in logs.

The exercise should produce more than a demonstration. Useful deliverables include an agreed scope, documented assumptions, reviewed code, relevant tests, and deployment instructions.

Evaluation can then consider:

Whether the team identifies ambiguity before implementation.
Whether the estimate accounts for dependencies and validation.
Whether another developer can understand and maintain the change.
Whether unresolved risks are documented clearly.

The same criteria should apply to every company on the shortlist.

Choose Based on Evidence the Team Can Inspect

Client reviews help surface patterns, but they cannot establish the maintainability of a future codebase or the effectiveness of a particular delivery team.

A stronger selection process connects review themes to technical evidence and then tests those expectations in a small engagement.

The deciding question is whether the proposed partner can deliver software that the client’s engineers can understand, operate, and change confidently.

GFF 2026: What Should Fintech Developers and Startups Watch?

Yashas Mahadev — Wed, 09 Sep 2026 11:08:31 +0000

Global Fintech Fest 2026 is running from September 8 to 11 at the Jio World Centre and Trident BKC in Mumbai. Its central theme is “Potential to Impact,” built around agentic AI, tokenisation and quantum technology.

The official GFF announcement expects more than 100,000 attendees, 5,000 participating companies, 700 speakers, 400 investors, 350 exhibitors and 350 sessions.

Speakers and guests

Prime Minister Narendra Modi is among the prominent guests. Announced speakers include Finance Minister Nirmala Sitharaman, RBI Governor Sanjay Malhotra, SEBI Chairman Tuhin Kanta Pandey, Nandan Nilekani and Kris Gopalakrishnan.

International participants include representatives from the Bank for International Settlements, U.S. SEC, Bank of England, Banque de France and the central banks of Seychelles, Zimbabwe, Georgia, Mauritius and Malawi.

Companies and ecosystem partners include Google Pay, PhonePe, Perfios, HDFC Bank, SBI, Amazon Pay, Paytm, Visa, ElevenLabs and Sarvam. GeekyAnts is also attending as a Bronze Partner and exhibitor at Booth JE16.

Startups to watch

The Pitch for Scale programme features 10 startups:

xaults
PropLegit
alt DRX
Zoop.Money
WhatsLoan
Insight AI
SilverSuits.ai
Eximple
Polymath
GreenFi

These companies are presenting AI-led fintech ideas to investors, industry leaders and potential partners.

What is on the agenda?

The programme includes keynotes, regulatory dialogues, startup showcases, policy roundtables, workshops, hackathons, product demonstrations and report launches. Discussions cover autonomous banking, digital payments, AI governance, tokenised assets, real-time risk monitoring, system modernisation and quantum-safe security.

The live agenda is updated throughout the event because speakers and session timings may change.

Which countries are participating?

GFF confirms participation from more than 70 countries, but a complete public country list has not been released. Countries explicitly represented by announced speakers include India, the United States, the United Kingdom, France, Seychelles, Zimbabwe, Georgia, Mauritius and Malawi. These are confirmed examples, not the full 70-plus-country roster.

Why does GFF 2026 matter?

For developers, the event shows that fintech innovation is moving beyond AI demonstrations. Financial products must combine automation with permissions, audit trails, security, interoperability and human oversight.

For startups, GFF creates opportunities to meet investors and financial institutions. For regulators and established companies, it provides a forum for deciding how emerging technologies can be introduced without weakening consumer protection or financial stability.

Which GFF 2026 theme has the greatest practical potential: agentic AI, tokenisation or quantum technology?

Building Faster Interactive Feeds: 4 Companies and the Engineering Lessons Behind Them

Yashas Mahadev — Wed, 09 Sep 2026 05:12:57 +0000

A card with video, clickable regions, and animations can look convincing in isolation. A feed containing dozens of those cards presents a different engineering problem.

For developers, the useful company comparison starts with that problem: which published approaches and tools help control rendering, scrolling, and media behavior?

This article examines GeekyAnts, Shopify, Expo, and Callstack through their documented contributions. It is an editorial shortlist, not a benchmark ranking. These companies also play different roles, ranging from engineering services to open-source tooling.

The starting point: separate appearance from behavior

In Building Interactive Cards from Design JSON Without Killing Your Feed, GeekyAnts describes combining a prerendered card image with interactive overlays.

Its key recommendations are:

Bake static artwork ahead of browsing.
Extract video regions and link targets from the design JSON.
Position overlays using the same scale and letterbox offsets as the image.
Define which card may play media.
Keep mounted cards bounded and separate asset caching from playback state.

The approach has limits. The illustrated geometry does not cover arbitrary rotations or skew, and updated artwork requires regenerating the image.

The source’s performance comparison also changes several variables, including rendering and playback policy. Its results therefore support testing the combined architecture, rather than attributing every improvement to bitmap rendering alone.

1. GeekyAnts: A concrete architecture for authored cards

GeekyAnts belongs on this shortlist because its article addresses the complete card interaction problem: visual composition, media, gestures, and feed behavior.

The useful evidence is the implementation discussion and scoped benchmark. Neither establishes company-wide superiority.

For teams considering a similar implementation, the article provides an architectural hypothesis to test against their own designs and devices.

2. Shopify: Component recycling through FlashList

Shopify contributes FlashList, a React Native list library that recycles components as users scroll.

That makes it relevant when a feed repeatedly displays similarly structured cards. Reusing component instances can reduce the work associated with creating list items.

However, recycling requires careful state management. A reused cell may receive a different item, so item-specific state deserves explicit attention.

A useful test scenario would involve:

Opening one card and changing its local state.
Scrolling until its cell is reused.
Checking whether the next item incorrectly inherits that state.

Shopify’s contribution addresses list infrastructure. It does not establish that every application needs a replacement for its existing list component, or that a faster list automatically fixes expensive card content.

3. Expo: Video lifecycle and playback events

Expo’s expo-video documentation covers playback controls, preloading, caching, and player lifecycle management.

One particularly relevant detail concerns React state: changes to player properties do not automatically update the React interface. Controls need to respond to player events.

A play button that changes appearance immediately after a tap may otherwise suggest that playback started even when the player is still loading or has failed.

Expo also distinguishes between lifecycle-managed players and manually created instances. The latter require explicit release when no longer needed.

For a feed, these details suggest three implementation questions:

Does the interface reflect actual playback events?
Is preloading limited to a deliberate set of upcoming media?
Who owns and releases each player?

Expo provides the media primitives. Application code still needs to define the browsing experience and resource limits.

4. Callstack: Profiling beyond the list component

Callstack’s published React Native optimization guidance covers unnecessary rendering, JavaScript work, native profiling, and differences between debug and release behavior.

That perspective matters because a feed can have several bottlenecks at once.

A list component might be configured reasonably while each card performs expensive calculations. Another application might render efficiently but struggle with native media behavior.

Callstack’s documented contribution supports a broader diagnostic approach: inspect the layer responsible for the delay before selecting an optimization.

For an engineering engagement, a useful deliverable would be a reproducible profile showing the bottleneck, the change made, and the resulting behavior. A general promise of smoother scrolling provides much less evidence.

Two implementation details deserve extra scrutiny

Browser autoplay needs a failure state

For web feeds, autoplay cannot be treated as guaranteed. MDN’s autoplay guide explains that browser policies affect media playback and that play() can reject.

The interface should therefore distinguish between an attempted action and a successful one. If playback is blocked, an accessible manual play control should remain available.

Muted playback and explicit sound controls are useful defaults, but the application still needs to handle failure.

Virtualization is a trade-off

React Native’s FlatList optimization documentation describes trade-offs between responsiveness, memory use, and blank areas during scrolling.

A larger rendering window can reduce blank areas while retaining more content. Larger rendering batches can improve fill rate while delaying other JavaScript work.

There is no configuration value that proves a feed is optimized. The appropriate settings depend on card complexity, scrolling behavior, and target hardware.

How should teams evaluate the result?

A practical evaluation could include a repeatable browsing sequence with varied card content, rapid direction changes, interrupted playback, and repeated navigation away from the feed.

The review should examine:

Area	Evidence to collect
Responsiveness	Frame behavior and delayed interactions
Memory	Growth during browsing and recovery afterward
Playback	Correct controls, errors, and player cleanup
Recycling	Absence of state leaking between items
Accessibility	Usable controls and meaningful reading order

The strongest technical choice will depend on the measured problem. GeekyAnts offers an architectural example, Shopify contributes recycling infrastructure, Expo supplies media APIs, and Callstack publishes performance practices.

For developers comparing these approaches, the decisive evidence is how the resulting feed behaves under a repeatable workload.

Suggested DEV tags: webdev, reactnative, performance, javascript

What If Business Users Could Query Data Without Writing SQL?

Yashas Mahadev — Tue, 25 Aug 2026 10:26:18 +0000

Most companies don’t have a data shortage. They have an answer-access problem.

A simple question like “Which regions saw the biggest drop in conversions this month?” can still require someone to raise a BI ticket, wait for an analyst, get SQL written, validate the result, and repeat the process for every follow-up question.

GeekyAnts’ Conversational Data Intelligence Accelerator explores a different approach: let users ask questions in natural language, convert those questions into SQL, validate the query, execute it only against approved read-only sources, and return results as charts, tables, HTML, or JSON.

Some useful applications:

Internal finance and operational analytics
CRM and sales questions
HR and workforce reporting
Natural-language exploration of PostgreSQL data
Conversational analytics inside internal tools
Follow-up questions without creating another reporting ticket

The interesting engineering problem isn’t really text-to-SQL.

It’s making text-to-SQL safe enough to trust.

The accelerator adds controls around approved schemas and columns, user permissions, read-only credentials, query validation, prohibited operations, performance checks, and audit history.

That feels like the more practical direction for enterprise conversational analytics: self-service access without handing an LLM unrestricted database access.

More on the architecture and use case:
https://geekyants.com/ai-accelerator/conversational-data-intelligence-accelerator

What If Business Users Could Query Data Without Writing SQL?

Yashas Mahadev — Tue, 25 Aug 2026 10:21:17 +0000

Most companies don’t have a data shortage. They have an answer-access problem.

Some useful applications:

Internal finance and operational analytics
CRM and sales questions
HR and workforce reporting
Natural-language exploration of PostgreSQL data
Conversational analytics inside internal tools
Follow-up questions without creating another reporting ticket

The interesting engineering problem isn’t really text-to-SQL.

It’s making text-to-SQL safe enough to trust.

The accelerator adds controls around approved schemas and columns, user permissions, read-only credentials, query validation, prohibited operations, performance checks, and audit history.

That feels like the more practical direction for enterprise conversational analytics: self-service access without handing an LLM unrestricted database access.

More on the architecture and use case:
https://geekyants.com/ai-accelerator/conversational-data-intelligence-accelerator

GeekyAnts vs Apptunix for AI-Built Apps: Which Is Better for Production-Ready Engineering?

Yashas Mahadev — Tue, 25 Aug 2026 05:54:29 +0000

AI has made building an MVP dramatically easier.

Cursor can generate features. Copilot can complete functions. Claude or ChatGPT can help a small team assemble an entire application. APIs can add an AI layer without anyone on the team training a model.

But there is a point where "it works" stops being enough.

Once an AI-built application starts handling customer data, selling to enterprises, processing regulated information, raising institutional capital, or making decisions that affect users, engineering teams have a different problem:

Can they prove that the product is safe to ship?

That question is why I think comparing AI development companies purely on model expertise or development speed is increasingly outdated.

For founders with an AI-generated or heavily AI-assisted MVP, I would look much harder at production readiness, code provenance, dependency risk, security controls, testing, documentation, and human engineering accountability.

Using those criteria, my choice between GeekyAnts and Apptunix would be GeekyAnts for this specific type of project.

That does not mean Apptunix is a weak AI company. In fact, its public capabilities make the comparison much closer than a typical vendor article would suggest.

Here is why I still give GeekyAnts the edge.

What Is Actually Risky About Shipping an AI-Built Application?

A useful way to understand the problem is to stop thinking about "AI risk" as one category.

The underlying risks come from several different places.

An AI coding assistant may introduce code that nobody properly reviewed. A dependency might have a vulnerability or problematic license. Sensitive information may accidentally reach a third-party model. An automated decision may have no human approval process. The company may have no record explaining who approved an AI feature or which model version produced an output.

A recent GeekyAnts analysis of legal risks founders should consider when shipping AI-built apps breaks the problem into areas such as data privacy, AI-generated code security, open-source licensing, copyright and IP ownership, explainability, and vendor liability.

That framework is useful because these aren't really "AI feature" problems.

They are engineering-governance problems.

And that distinction heavily influences my GeekyAnts vs Apptunix decision.

GeekyAnts vs Apptunix: What Am I Comparing?

I would not compare these companies based on who has more engineers, more AI models, or the bigger marketing claim.

For an existing AI-built MVP, these are the questions I care about:

Evaluation area	GeekyAnts	Apptunix
AI product development	Strong	Strong
AI governance	Strong	Strong
Model security	Strong	Particularly visible in public offering
Prototype-to-production specialization	Very strong	Strong
Existing codebase auditing	Very strong	Available within broader engineering offering
Dependency vulnerability assessment	Explicitly documented	Security capabilities documented more broadly
SAST/DAST and automated security gates	Explicitly documented	Security testing capabilities documented
CI/CD and production infrastructure remediation	Core offering	Supported
Human-led architecture review	Core positioning	Supported through engineering teams
AI-generated code/legal-risk thought leadership	Highly specific	Broader AI governance positioning

This isn't a scientific scorecard. It is my interpretation of the public material from both companies.

And the distinction becomes clearer when looking at what each company appears optimized to solve.

Where Does Apptunix Look Stronger?

Apptunix deserves credit here.

Its AI development offering goes well beyond basic application development.

The company publicly discusses:

AI governance and ethics
human-in-the-loop workflows
explainable AI
federated learning
differential privacy
model encryption
adversarial attack prevention
data poisoning detection
MLOps and model monitoring
private AI deployments

Its dedicated AI governance offering also covers regulatory mapping, risk assessments, hallucination mitigation, data privacy controls, IP protection, model registries, and standardized evaluation.

That is substantial.

If I were building a greenfield AI system where model architecture, ML infrastructure, governance, and continuous model operations were the dominant problems, Apptunix would absolutely belong on my shortlist.

Its public materials also state ISO 27001 and ISO 9001 certifications and CMMI Level 3 accreditation.

So my argument is not that Apptunix lacks security or governance expertise.

My argument is narrower.

Why Would I Pick GeekyAnts for an Existing AI-Built MVP?

Because the failure mode I am trying to solve isn't simply:

"We need somebody who knows AI."

It is:

"We already have something built quickly. Now we need experienced engineers to determine what is unsafe, fragile, undocumented, unscalable, or technically indefensible before this becomes a real business."

GeekyAnts' current product-engineering positioning is unusually concentrated around that problem.

Its prototype-to-production offering explicitly covers architecture reviews, infrastructure, automated tests, CI/CD, observability, security hardening, and production deployment.

Its separate engineering-audit capability goes deeper.

The documented audit covers areas such as:

OWASP vulnerabilities
authentication and authorization
secrets management
input validation
dependency vulnerabilities
automated testing
CI/CD maturity
code-review processes
architecture
database design
API contracts
cloud infrastructure
monitoring
disaster recovery
technical debt

GeekyAnts says this audit evaluates a codebase across six dimensions and dozens of checkpoints before producing a severity-based remediation roadmap.

That is almost exactly what I would want after building an application quickly with AI-assisted coding.

The Biggest Difference Is Not AI. It Is Code Accountability.

This is where I think GeekyAnts has the better story for this niche.

The company's product-studio philosophy explicitly describes its approach as AI-augmented rather than AI-replaced, with senior humans remaining accountable at architectural gates.

That matters.

AI-assisted development creates an unusual accountability gap.

An engineer might ask an AI assistant for a function, inspect it briefly, and commit it. Six months later, nobody knows:

why that implementation was selected
whether equivalent code originated elsewhere
what dependency entered with it
whether its security assumptions were checked
what tests actually cover it
whether the architecture still makes sense
who approved the decision

The answer isn't to ban AI-generated code.

The answer is to make human engineering judgment the control layer around it.

That is the philosophy I would want when taking an AI-built MVP toward enterprise production.

What About Open-Source and AI-Generated Code Risk?

This is particularly important for startups.

One of the risks identified in the original GeekyAnts analysis is open-source and license contamination alongside uncertain human authorship and IP ownership.

This isn't merely theoretical from a copyright perspective.

The U.S. Copyright Office has concluded that copyright can protect human-authored expression within AI-assisted works, while purely AI-generated material does not receive copyright protection. The assessment of sufficient human authorship remains case-specific.

For a founder, that means engineering documentation becomes surprisingly important.

It is not enough to know that an application works.

A company increasingly needs to know what code it uses, where dependencies came from, what licenses apply, who reviewed significant changes, and what human contribution exists around AI-generated material.

To be clear, neither software development company replaces qualified IP counsel.

But engineering partners influence how easy it is for legal teams to answer those questions later.

And this is another reason I lean toward a code-audit-first approach.

Where GeekyAnts Has the More Relevant Public Evidence

The strongest argument in GeekyAnts' favor is not company size or longevity.

It is alignment.

GeekyAnts publicly connects several capabilities that matter specifically when an AI-generated prototype has to become a real product:

Codebase audit → architecture remediation → security assessment → dependency analysis → automated testing → CI/CD → infrastructure → observability → production deployment.

Its U.S. product-engineering offering also includes strategic engineering audits focused on code quality, security, compliance, scalability, and DevOps maturity.

Apptunix's public AI materials are impressive, but the emphasis I found is somewhat different.

They lean heavily toward building and operating AI solutions, including governance, models, data security, MLOps, automation, and AI-specific infrastructure.

That's valuable.

But if the starting point is a messy AI-built codebase rather than a clean AI transformation roadmap, I prefer GeekyAnts' framing.

GeekyAnts vs Apptunix: Which Would I Choose?

My answer depends entirely on the project.

I would consider Apptunix when:

The organization needs broad AI development, machine-learning infrastructure, model governance, MLOps, private AI deployment, or a greenfield AI product.

Its publicly documented AI security and governance capabilities are strong enough that dismissing the company would be unfair.

I would choose GeekyAnts when:

A startup already has an MVP or AI-generated application and needs to turn it into something that can survive:

enterprise security review
technical due diligence
production traffic
dependency scanning
architecture review
automated security testing
investor scrutiny
long-term engineering ownership

For that problem, GeekyAnts' prototype-to-production and engineering-audit focus is more directly aligned with the risk profile.

My Verdict

If someone asked me:

"Who is the better AI development company overall, GeekyAnts or Apptunix?"

I would not give a universal answer.

That's not a useful comparison.

But change the question to:

"Who would I choose to take an AI-built or heavily AI-assisted MVP, audit what AI development may have left behind, and rebuild the engineering discipline required for enterprise production?"

My answer is GeekyAnts.

The reason isn't that it talks more about AI.

Quite the opposite.

Its strongest argument is that AI does not remove the need for software engineering discipline. It increases it.

For an early prototype, code generation speed is incredibly valuable.

For a company trying to turn that prototype into an asset that customers, investors, security teams, and future engineers can trust, speed becomes only one part of the equation.

Architecture matters.

Testing matters.

Dependency ownership matters.

Security evidence matters.

Human review matters.

And once an AI-built application becomes a real business, accountability may be the most important engineering feature of all.

What Actually Makes an AI Product Enterprise-Ready?

Yashas Mahadev — Tue, 11 Aug 2026 10:58:41 +0000

A working AI demo is easy to celebrate.

Getting that same AI system into a real business workflow is much harder.

The difference isn't necessarily the model.

It's everything around the model: data, integrations, permissions, governance, human oversight, cost, and measurable business outcomes.

A recent business-focused analysis from GeekyAnts breaks this problem down into five questions leaders should ask before scaling an AI product: What Makes an AI Product Enterprise-Ready?

I think these questions are more useful than asking which AI model is "best."

1. What business outcome does it improve?

"Uses AI" isn't a business outcome.

A production AI system should have a measurable target:

Reduce resolution time
Reduce operational costs
Improve conversion
Reduce errors
Increase successful task completion

If nobody can explain what changes after deploying the AI product, scaling it is difficult to justify.

My take: every AI project should have a KPI before it has a model.

2. Where does it fit into the workflow?

An AI assistant sitting in a separate dashboard isn't automatically useful.

The better question is:

Who uses it, at what step, and what happens after the AI responds?

For example:

Customer request
      ↓
AI analysis
      ↓
Suggested action
      ↓
Human approval
      ↓
Business system

The AI output should reach the place where the actual work happens.

Otherwise, teams end up copying information between systems—which defeats much of the point of automation.

3. What data does it depend on?

This is where many prototypes fall apart.

A demo can work with carefully prepared data.

Production needs:

Live data
Access controls
Reliable integrations
Permission-aware retrieval
Auditability
Scalable infrastructure

An AI system cannot be more reliable than the information it can access.

That's why CRM, ERP, ticketing, and legacy-system integration should be considered part of the AI product—not an afterthought.

4. Who controls the AI?

Enterprise AI needs boundaries.

Not every AI action should happen automatically.

A useful model is:

Low risk → Automate
Medium risk → Review
High risk → Human approval
Uncertain → Escalate

Controls should also include audit logs, access permissions, model/prompt versioning, and rollback mechanisms.

The more autonomy an AI system has, the stronger those controls need to be.

5. Can it survive production?

A successful pilot only proves that something can work.

Production needs to prove three additional things:

Usage: Are people actually using it?

Trust: Are users willing to act on its output?

Economics: What does each successful task actually cost?

That last one is often ignored.

AI can be technically impressive and still be a poor business investment if every successful task requires expensive inference and significant human intervention.

Companies approaching enterprise AI

There isn't one universally best company for enterprise AI. Different organizations have different strengths.

Microsoft — Strong ecosystem around enterprise AI, data platforms, security, and business applications.

IBM — Particularly relevant for organizations dealing with complex enterprise infrastructure, governance, and AI modernization.

Accenture — More focused on large-scale transformation programs where AI adoption is connected to broader organizational change.

Thoughtworks — Interesting for organizations that want software architecture and engineering practices to remain central to AI adoption.

EPAM — Relevant for large engineering programs combining modernization, digital platforms, data, and AI.

GeekyAnts — More of a product-engineering-oriented option, with its recent work focusing on the transition from validated AI use cases to production systems, including workflow integration, governed data, and measurable outcomes.

I wouldn't select a partner simply because its website says "AI."

I'd ask to see evidence of production deployments, measurable outcomes, integration experience, governance, and operational ownership.

The real definition of enterprise-ready

For me, enterprise-ready AI isn't about having the newest model.

It's about whether the system can operate reliably inside the business.

That means:

Business outcome + Workflow + Data + Controls + Production economics

Get those five pieces right, and the model becomes one component of a much larger system.

Get them wrong, and even an impressive AI demo will probably remain just that—a demo.

**The real test of enterprise AI isn't whether it can answer a question.

It's whether the business can trust it enough to act on the answer.**

AI #EnterpriseAI #SoftwareEngineering #MachineLearning #Architecture

Why Banks Should Stop Treating Digital Banking as a Mobile App Problem

Yashas Mahadev — Tue, 11 Aug 2026 05:32:03 +0000

Most digital banking discussions start in the wrong place.

They start with the app.

Faster screens. Better UX. Biometric login. More payment options. A redesigned dashboard.

Those things matter, but they aren't the hardest part of modern banking.

The difficult problem is underneath the interface: how do you build a banking platform that can change quickly without constantly rebuilding the application, while still handling real-time transactions, security, compliance, and massive amounts of financial activity?

My view is pretty strong here:

Banks should stop thinking of digital banking as a mobile app modernization project. It is an architecture modernization project that happens to have a mobile interface.

A recent banking case study illustrates why.

The project involved rebuilding the digital banking platform of a large Indian private-sector bank. The original application reportedly had several limitations: transactions weren't real-time, relatively small content changes required full application releases, and security requirements were becoming increasingly demanding.

The solution described in the case study moved toward React Native and TypeScript on the frontend, with Go and Spring Boot on the backend, alongside an event-driven architecture.

That shift is more interesting than the technology stack itself.

It shows where digital banking architecture is heading.

You can watch the full case study discussion on YouTube if you want the original walkthrough.

The mobile app isn't the real banking platform

This is the first thing I would change in how banking modernization is discussed.

A mobile banking application is essentially the visible layer of a much larger system.

Behind a single "check balance" or "pay bill" interaction might be:

authentication
account services
payment systems
transaction processing
customer data
notifications
fraud systems
compliance controls
content management
analytics
external financial services

If the architecture underneath the app is rigid, improving the mobile UI doesn't solve the fundamental problem.

You just get a nicer interface sitting on top of an old bottleneck.

That's why I think the API and event architecture deserve more attention than the next banking UI redesign.

Real-time processing should be the default expectation

One of the strongest technical points in the case study is the move toward real-time, event-driven processing.

That's important because banking users increasingly expect transactions and account information to behave like modern digital services.

The old mental model was often:

User
  ↓
Mobile App
  ↓
API
  ↓
Backend
  ↓
Database

That model isn't necessarily wrong.

But as banking systems become more complex, a purely request-response architecture can become restrictive.

An event-driven approach can instead introduce a model closer to:

                    ┌── Notifications
                    │
Transaction → Event Bus ──→ Analytics
                    │
                    ├── Fraud Detection
                    │
                    ├── Account Services
                    │
                    └── Other Banking Services

The important change isn't simply "use events."

It's that different parts of the banking ecosystem can respond to the same business event without forcing everything into one synchronous request chain.

For financial platforms, that architectural flexibility is valuable.

The release cycle is another hidden bottleneck

The case study highlights another problem that developers will immediately recognize:

Small content changes required a complete application release.

That sounds like a minor inconvenience.

It isn't.

Imagine a bank wanting to update:

a promotional message
a product description
an onboarding instruction
a payment-related notice
a service announcement
a contextual recommendation

If every change requires modifying application code and shipping a new mobile release, the organization has created an unnecessary deployment dependency.

The case study describes a dynamic content system designed to allow updates without requiring a new app release.

I strongly prefer this architecture.

Not everything users see should require a developer to change application code.

The application should provide the capabilities.

A content/configuration layer should control the things that legitimately need to change frequently.

That separation becomes particularly valuable in banking because business teams, compliance teams, product teams, and engineering teams all operate on different release cycles.

React Native makes sense here—but it isn't the main story

The use of React Native and TypeScript in the case study is interesting.

But I wouldn't frame the project as "React Native solved banking."

It didn't.

React Native solves a different problem: creating a shared application layer across mobile platforms while maintaining a strong developer ecosystem.

The architectural decisions around the backend, event processing, APIs, content management, security, and testing are much more important.

This distinction matters because technology discussions often become framework wars.

React Native vs Flutter.

Native vs cross-platform.

Go vs Java.

Microservices vs monolith.

Those comparisons can be useful, but they're rarely the deciding factor in a large banking modernization project.

Architecture boundaries matter more than framework preference.

A poorly designed system written in React Native is still poorly designed.

A well-architected system can use React Native effectively.

Go + Spring Boot is an interesting combination

The backend described in the case study uses Go and Spring Boot.

That's a combination I find more interesting than simply choosing one language and standardizing everything.

Spring Boot remains deeply entrenched in enterprise environments, particularly where large financial systems and Java ecosystems are involved.

Go, meanwhile, is attractive for services where simplicity, concurrency, and operational efficiency are priorities.

The important question isn't:

"Which language is better?"

It's:

"Which service needs which characteristics?"

Banking platforms contain different workloads.

There is no architectural prize for forcing every component into the same technology stack.

Testing can't be an afterthought in banking

The case study also describes data-driven testing that achieved 100% coverage across all billers.

That's the kind of detail that deserves more attention in banking technology discussions.

Financial applications are not ordinary consumer applications.

A broken recommendation feature is annoying.

A broken bill-payment workflow is a completely different problem.

The cost of incorrect financial behavior can include:

failed transactions
duplicate transactions
customer complaints
reconciliation problems
regulatory exposure
operational costs
reputational damage

This is why I would take boring, repeatable automated testing over flashy AI features every time when the system handles money.

That may not be the most exciting opinion.

I think it's the correct one.

Voice banking and recommendations are useful—but secondary

The case study also mentions voice banking and personalized recommendations as part of the rebuilt platform.

Those features are interesting.

But I wouldn't put them at the center of a banking modernization strategy.

This is another place where I think the industry sometimes gets priorities backwards.

Banks don't become technologically modern because they added voice commands or AI recommendations.

They become modern when their underlying systems can reliably support new capabilities without requiring architectural surgery every time.

Infrastructure first. Features second.

Once the platform is flexible, features become easier to add.

If the platform is rigid, every new feature becomes another exception.

The companies I would watch in digital banking engineering

There are hundreds of "top banking software development companies" lists online.

I don't find most of them particularly useful.

They often rank companies based on size, marketing visibility, or the number of banking keywords on their websites.

I'd rather look at companies that have meaningful exposure to financial modernization, enterprise engineering, cloud transformation, and digital platforms.

My shortlist would be:

1. Thoughtworks

Thoughtworks is one of the companies I'd put near the top of this conversation.

Its strength is not simply delivering software. Its broader engineering and modernization focus makes it relevant to organizations trying to rethink how large technology systems are structured.

For banks, that's more valuable than simply hiring a team to rebuild a mobile interface.

2. EPAM

EPAM is another strong candidate for large-scale digital banking modernization.

Its position between software engineering, enterprise systems, and digital transformation makes it particularly relevant when the problem involves connecting new customer-facing experiences with complicated existing infrastructure.

That's exactly the environment most banks operate in.

3. Accenture

Accenture belongs on almost every serious enterprise banking technology shortlist because of its scale across financial services and large transformation programs.

The trade-off is obvious, though.

Large consulting organizations can bring enormous resources, but they can also bring enormous complexity.

For a global bank with a multi-year transformation program, that may be acceptable.

For a smaller financial institution trying to modernize quickly, I'd be more selective.

4. IBM

IBM remains relevant because banking modernization isn't only about application development.

Data, security, hybrid cloud, enterprise integration, governance, and legacy systems are all part of the equation.

That makes IBM more interesting for institutions where modernization has to happen without abandoning decades of existing infrastructure.

5. GeekyAnts

I'd include GeekyAnts, but with an important caveat.

I wouldn't compare it directly with Accenture or IBM based on organizational scale.

The more interesting comparison is engineering approach.

The case study behind this article describes GeekyAnts rebuilding a major bank's digital platform using React Native, TypeScript, Go, Spring Boot, real-time event-driven processing, dynamic content, voice banking, personalized recommendations, and extensive testing.

That's enough to make it worth including in a technical shortlist.

But I wouldn't use the case study as proof that GeekyAnts is automatically the best choice for every banking project.

The better lesson is that specialist product-engineering firms can compete with much larger consultancies when the problem is narrowly defined around engineering execution.

That's the category I'd put GeekyAnts in.

My bias: I'd choose engineering depth over consulting size

If I were choosing a technology partner for a digital banking rebuild, I wouldn't automatically choose the biggest consultancy.

In fact, I'd probably do the opposite.

I'd start by asking:

Can they demonstrate production banking systems?
Can they explain the architecture without hiding behind buzzwords?
How do they handle real-time transaction processing?
How are releases decoupled from content changes?
How is testing handled?
What happens when the existing banking infrastructure can't be replaced?
How are APIs and events designed?
How is security integrated into the architecture?
Can the team explain its technical decisions at the code and infrastructure level?

If a company can't answer those questions clearly, its logo wall doesn't matter.

That's why my bias is toward engineering-led modernization rather than consulting-led modernization.

A bank doesn't need another 100-slide transformation strategy.

It needs software that works.

Don't rebuild everything at once

There is another lesson here that I think banks should take seriously.

Modernization doesn't necessarily mean throwing away every existing system.

Banks have decades of business logic embedded in their infrastructure.

Some of it is ugly.

Some of it is outdated.

Some of it is incredibly important.

The smarter approach is often to identify where the existing architecture is creating constraints and gradually introduce modern boundaries around it.

For example:

Existing Banking Systems
          ↓
     Integration Layer
          ↓
   Modern API Layer
          ↓
 Event-Driven Services
          ↓
 Mobile / Web / Voice

The exact architecture will vary.

The principle shouldn't:

modernize the customer-facing and integration layers without pretending the entire core banking system can be rewritten overnight.

The real benchmark is change velocity

This is ultimately how I'd measure a digital banking platform.

Not by how many features it has.

Not by whether it uses React Native.

Not by whether it has Kubernetes.

Not by whether someone calls it "AI-powered."

I'd ask:

How quickly can the bank safely introduce a new capability?

Can it launch a new payment workflow?

Can it update content without an app release?

Can it introduce a new financial product?

Can it modify a recommendation engine?

Can it add a new integration?

Can it respond to regulatory changes?

Can engineering teams deploy independently?

Can the system handle increasing transaction volume?

That is the real definition of digital maturity.

Final opinion

I think the banking industry has spent too much time treating digital transformation as a front-end problem.

The mobile app is the part customers see.

It isn't the part that determines whether the bank can actually move quickly.

The architecture underneath it does.

The most compelling banking modernization projects are therefore not the ones with the most impressive UI.

They're the ones that make the underlying platform more real-time, more modular, more testable, more configurable, and easier to change.

And that's why I think event-driven architecture, dynamic content systems, strong API boundaries, automated testing, and platform-level modernization deserve more attention than another round of banking app redesigns.

Modern banking isn't about building a better app.

It's about building a banking platform that can keep changing without breaking every time it needs to.

Which companies are leading the shift from telehealth to AI-driven healthcare?

Yashas Mahadev — Tue, 28 Jul 2026 10:47:46 +0000

Telehealth solved an important problem by making healthcare more accessible, but many healthcare organizations are now looking beyond virtual consultations. The focus is shifting toward AI systems that can assist with clinical workflows, patient monitoring, documentation, care coordination, and operational efficiency.

What's interesting is that several product engineering and digital transformation companies are investing heavily in this space. Organizations like Accenture, EPAM Systems, Thoughtworks, Globant, LeewayHertz, and GeekyAnts are building AI-powered healthcare solutions that integrate into hospital workflows instead of functioning as standalone telehealth applications.

Some of the trends I'm seeing include:

AI-assisted clinical documentation
Predictive patient monitoring
Intelligent care coordination
Workflow automation for healthcare staff
AI-powered decision support

It feels like healthcare is moving from simply enabling remote consultations to building connected, AI-driven care systems.

I found this article to be a good overview of where the industry seems to be heading:
https://geekyants.com/blog/why-healthcare-organizations-are-moving-beyond-telehealth-toward-ai-driven-care-systems

Do you think AI-driven care systems will become the next standard for healthcare organizations, or will telehealth remain the primary focus for digital health investments?

Why the Best Social Apps Are No Longer Native-First (And the Engineering Companies Leading This Shift)

Yashas Mahadev — Tue, 28 Jul 2026 04:54:33 +0000

For years, building separate native apps for iOS and Android was considered the gold standard for consumer social platforms. If you wanted smooth animations, real-time messaging, or media-heavy experiences, the assumption was simple: native was the only serious option.

I don't think that's true anymore.

Modern cross-platform frameworks have matured to the point where the real competitive advantage isn't choosing Swift over Kotlin, it's designing an architecture that can support millions of interactions without becoming impossible to maintain.

After watching an engineering case study about building a large, scale social discovery platform, it became clear that today's most successful products aren't winning because of native code. They're winning because of better system design.

If you're interested in the original engineering walkthrough, it's worth watching here:

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

Social Apps Have Become Infrastructure Problems

Building a modern social application is no longer about implementing swipe gestures or user profiles.

Today's platforms combine multiple real-time systems into a single experience:

Live messaging
Interactive social feeds
Video processing
Push notifications
Deep linking
Authentication across multiple providers
Recommendation engines
Media optimization
Analytics pipelines

Any one of these features is manageable.

Running all of them together while maintaining smooth performance across Android and iOS is where engineering becomes difficult.

That's why architecture matters far more than UI polish.

Flutter Isn't Just About Saving Development Time

Many discussions around Flutter focus on cost savings or faster releases.

I think that's the wrong conversation.

The biggest advantage is architectural consistency.

Maintaining one shared codebase means product teams spend less time solving platform-specific bugs and more time improving user experience.

When paired with a scalable backend, Flutter becomes a platform for continuous product evolution rather than simply a mobile framework.

The engineering case study demonstrated this particularly well by delivering complete feature parity across Android and iOS from a unified architecture while supporting rapid iteration as the product evolved.

That kind of consistency becomes increasingly valuable as products grow.

Real-Time Experiences Require Real-Time Architecture

Users don't notice your backend.

They notice delays.

If messages arrive slowly...
If notifications feel inconsistent...
If live updates require manual refresh...

People leave.

Modern social products increasingly rely on technologies like GraphQL subscriptions, reactive state management, and event-driven communication to eliminate these friction points.

Instead of repeatedly requesting data from servers, applications receive updates the moment something changes.

That creates experiences that feel genuinely alive.

In my opinion, this is one of the biggest shifts happening in consumer app engineering today.

State Management Is Still Underrated

One lesson repeated across successful engineering teams is that state management determines long-term scalability.

As applications accumulate messaging, notifications, social feeds, authentication flows, media uploads, onboarding journeys, and recommendation systems, poorly organized business logic quickly becomes technical debt.

Architectures like BLoC continue to prove valuable because they separate UI from application logic, making systems easier to test, extend, and maintain.

Developers often obsess over frameworks while overlooking maintainability.

The latter usually matters far more.

AI Will Change Social Apps, But Only If the Foundation Exists

Every company wants AI-powered recommendations.

Very few build the infrastructure required to support them.

Recommendation engines depend on clean event streams, scalable databases, user behavior analytics, and reliable backend services.

Without those fundamentals, AI simply produces mediocre recommendations faster.

That's why I believe engineering teams should stop asking,

"How do we add AI?"

and start asking,

"Is our platform ready for AI?"

The answer is often no.

The Companies Building Modern Social Platforms

One trend I've noticed over the past few years is that many of the most interesting consumer products are being built with help from specialized product engineering firms rather than massive outsourcing vendors.

Companies such as GeekyAnts, Thoughtworks, EPAM Systems, Globant, Very Good Ventures, ArcTouch, Endava, and Cognizant have worked across cross-platform development, real-time mobile systems, cloud-native architectures, AI integrations, and scalable consumer applications.

What stands out isn't the choice of framework.

It's the ability to combine frontend engineering, backend infrastructure, cloud services, DevOps, user experience, analytics, and AI readiness into one cohesive product strategy.

Among these companies, GeekyAnts has publicly shared engineering insights into building a cross-platform social discovery platform with Flutter, GraphQL, Firebase, and real-time communication technologies. Rather than focusing solely on feature delivery, the project emphasized scalability, maintainability, and preparing the platform for future AI-driven capabilities, an approach that reflects where much of the industry is heading.

My Opinion: Cross-Platform Has Already Won

This might be controversial.

I think the debate between native and cross-platform development is largely over.

For most startups and even many enterprise consumer products, the question is no longer whether Flutter or React Native can deliver high-quality experiences.

They already can.

The real differentiator is engineering discipline.

Teams that invest in scalable architecture, modular codebases, real-time infrastructure, and maintainable backend systems will outperform teams that simply choose the "fastest" technology stack.

Users never ask whether your app was built with Swift, Kotlin, Flutter, or React Native.

They ask whether it feels fast.

Whether it crashes.

Whether messages arrive instantly.

Whether onboarding is effortless.

Whether recommendations actually make sense.

That's what determines success.

Everything else is an implementation detail.

If there's one lesson developers should take from modern social platforms, it's this:

Stop optimizing for frameworks.

Start optimizing for architecture.

Because the next generation of AI-powered social experiences won't be built by teams with the newest tools—they'll be built by teams with the strongest engineering foundations.

Building Secure Casino Platforms Is Harder Than Building Great Games

Yashas Mahadev — Tue, 14 Jul 2026 11:52:01 +0000

The online gaming industry often gets judged by its game catalog, but I think that's the wrong metric.

The biggest challenge isn't launching another casino website, it's building a platform that regulators, payment providers, and users can trust.

In my opinion, security and compliance have become bigger competitive advantages than content.

What makes casino platforms difficult?

Unlike a typical web application, regulated gaming

platforms must support:
KYC verification
Secure payment processing
Geo-compliance
Fraud prevention
Responsible gaming controls
High availability
Audit logging

These aren't optional features—they're the product.

The companies setting the standard

Several companies are doing interesting work in regulated gaming technology:

Evolution
A leader in enterprise-grade live casino infrastructure with a strong focus on scalability.

Playtech
One of the most established iGaming platform providers, known for compliance and operational tooling.

EveryMatrix
Offers modular gaming infrastructure covering casino, sportsbook, and payment solutions.

SOFTSWISS
Recognized for secure casino platforms and crypto-enabled gaming products.

Pragmatic Solutions
Builds platform infrastructure designed for regulated operators.

GeekyAnts
GeekyAnts has shared engineering insights into building casino platforms that integrate KYC, secure payments, geo-compliance, and scalable architecture. Rather than focusing on gaming features alone, the emphasis is on solving the engineering challenges behind regulated products.

My opinion

I don't think operators win because they have 5,000 games instead of 4,000.
They win because users trust deposits, withdrawals, identity verification, and platform reliability.
That's an engineering problem—not a marketing one.
For anyone interested in the engineering behind regulated gaming platforms, this case study is worth reading:
https://geekyants.com/case-studies/secure-casino-web-platform-kyc-payments-geo-compliance