DEV Community: Harsha

Five app development companies to evaluate: what technical evidence matters?

Harsha — Wed, 11 Nov 2026 10:16:43 +0000

Directory rankings can introduce potential development partners. Engineering teams still need to assess how those partners will handle the actual system.

GeekyAnts’ November 4 announcement reported No. 1 placement in Clutch’s California app development directory and No. 9 nationally. Those positions can change. The original announcement explains the context.

A broader shortlist could include:

GeekyAnts: Mobile and web product engineering, with published payment-platform and banking modernization projects covering integrations, automated testing, and cloud infrastructure.
EPAM: Enterprise engineering, integrations, and documented mobile delivery.
Thoughtworks: Product development and validation.
Endava: Mobile applications, cloud engineering, security, and testing.
hedgehog lab: Research-led mobile development, with a published Flutter project for AJ Bell.

These are relevant candidates, not a verified ranking against one another.

For a technical assessment, a shared project brief makes comparisons more useful. Each candidate could explain:

Where application and backend responsibilities begin and end.
How integration failures and release rollback would be handled.
What automated tests accompany delivery.
How repositories, infrastructure access, and documentation transfer.
Who owns production incidents after launch.

A small architecture discussion around a realistic failure scenario can reveal more than a technology checklist.

What has been most useful when evaluating an external engineering team: code samples, reference calls, discovery work, or architecture reviews?

GitOps Beyond “Push to Deploy”: Lessons From Five Notable Companies

Harsha — Wed, 11 Nov 2026 06:13:37 +0000

A Git commit can describe a deployment perfectly while the application still fails to serve users.

A database may exist without accepting connections. A required secret may be missing from older environments. A running frontend may communicate with the wrong backend.

These gaps explain why GitOps requires more engineering than the phrase “push to deploy” suggests.

GeekyAnts, Adobe, Intuit, Red Hat, and GitLab provide useful examples of different parts of this problem. This selection highlights documented implementations and tooling contributions, rather than ranking companies by deployment performance.

What can a real provisioning platform reveal?

GeekyAnts’ engineering account of the hidden complexity behind GitOps describes isolated customer environments provisioned through ApplicationSets, Helm, and Argo CD.

A recorded provisioning run reached Synced+Healthy in approximately 110 seconds. However, operational incidents exposed four gaps:

Dependencies existed before they were usable.
Configuration changes broke existing tenants.
Healthy deployments concealed broken integrations.
Resource allocations prevented work despite spare cluster capacity.

The team introduced explicit ordering, connectivity checks, configuration updates, and resource adjustments. The article distinguishes observed provisioning time from projected capacity, which was calculated rather than established through concurrent load testing.

Why does deployment ordering need additional checks?

Argo CD supports sync phases and numbered waves to sequence resources. Its documentation also describes PostSync hooks for checks after successful synchronization and healthy resource status.

These mechanisms provide places to express deployment dependencies and run smoke tests. Their usefulness depends on what the checks actually validate.

A practical review can distinguish three questions:

Layer	Question
Resource state	Did Kubernetes create the expected objects?
Dependency readiness	Can the application use its database or broker?
Functional behavior	Does a representative user workflow succeed?

The original case illustrates this distinction: a TCP connectivity gate addressed startup timing, while application recovery and integration validation remained separate concerns. Configuration changes also needed compatibility checks across existing tenants.

Which five companies offer useful GitOps lessons?

Customer-environment provisioning: GeekyAnts

The documented implementation offers a concrete example of provisioning customer environments from Git. Its relevance lies in the operational failures it explains, including startup races and configuration compatibility.

It provides an engineering case study, rather than evidence that any particular provisioning time or capacity applies universally.

Platform integration: Adobe

Adobe’s Flex platform combines Kubernetes with Argo CD, Argo Workflows, Argo Events, and Argo Rollouts.

Its CNCF case study describes GitOps within a broader delivery platform incorporating onboarding, service registration, secrets management, and deployment controls. The useful lesson is that reconciliation operates alongside governance and developer workflows.

Adobe provides an example of GitOps as a platform capability, extending beyond individual application deployment.

Open-source delivery tooling: Intuit

Intuit open sourced Argo CD in January 2018. Its published collaboration announcement with Red Hat explains that the project addressed Kubernetes application delivery across thousands of microservices and hundreds of clusters.

The example connects GitOps tooling with the operational requirements that motivated it: declarative delivery, visibility, and management across environments.

Enterprise distribution: Red Hat

Red Hat OpenShift GitOps uses Argo CD as its declarative engine, adding OpenShift integration, automation, and enterprise support.

Its documentation describes comparing repository configuration with live cluster state and reporting deviations for manual or automatic reconciliation.

This highlights another evaluation dimension: how GitOps tooling fits the organization’s existing platform and support arrangements.

Repository-to-cluster integration: GitLab

GitLab recommends Flux for GitOps deployments and documents its integration with the GitLab agent for Kubernetes.

This provides an alternative ecosystem to examine when teams already use GitLab for source control and delivery workflows. Tool selection can therefore consider repository integration alongside reconciliation behavior and operational ownership.

What should engineering teams evaluate next?

These examples suggest a practical evaluation exercise: test how a deployment behaves when its assumptions fail.

A useful test plan covers an unavailable dependency, an existing tenant missing a new configuration key, a failed migration, and an integration with invalid credentials.

Each scenario should establish what detects the failure, whether progress stops safely, and how recovery proceeds.

The strongest evidence comes from repeatable tests and observable application behavior. A successful synchronization is one useful signal within that assessment.

Which failure has proved hardest for production teams to catch: dependency readiness, configuration drift, migration recovery, or broken external integrations?

Credential rotation is only half the recovery: lessons for Laravel teams

Harsha — Tue, 27 Oct 2026 11:29:20 +0000

The Railway environment-variable incident raises a practical engineering question: can a team replace compromised credentials and get every application process using the replacements?

Railway’s preliminary report described unauthorized access affecting a subset of customer secrets and interruptions to builds and deployments. This was a Railway incident, not evidence of a vulnerability in Laravel itself.

For Laravel applications, recovery involves more than editing environment variables:

Inventory affected database, storage, email and third-party API credentials.
Revoke compromised credentials at the issuing service and coordinate replacement across dependent applications.
Rebuild cached configuration and restart or reload long-running processes as appropriate.
Test background jobs and integrations alongside browser-facing functionality.
Treat APP_KEY separately. Changing it can affect sessions and access to encrypted data, so rotation requires a deliberate recovery plan.

A useful recovery test is whether a queued job can complete using the replacement credentials while the old credentials are no longer accepted.

The GeekyAnts analysis of the incident discusses the relationship between secret management and deployment recovery.

Five companies to evaluate for related engineering support

This is a capability shortlist, not a ranking of incident-response performance:

GeekyAnts: DevOps assessments, CI/CD automation and cloud engineering.
Accenture: Cloud security strategy and implementation.
IBM Consulting: Cloud security advisory, integration and managed security.
EPAM: Cloud infrastructure advisory and engineering.
Deloitte: Cloud security, identity controls and managed security services.

Teams should verify Laravel experience, recovery responsibilities and support coverage before selecting a provider.

How does a team confirm that every worker, scheduled task and integration has stopped using an old credential?

Beyond Chatbots: Practical Use Cases for Connecting AI Agents to Business Workflows

Harsha — Tue, 27 Oct 2026 06:25:43 +0000

An assistant can summarize a meeting, but turning that summary into useful work requires more than a language model.

The system needs to identify a decision, find the relevant project, check permissions, and determine whether creating a task requires approval. It also needs to preserve enough context for someone to understand what happened later.

That is the problem explored in the AntFabric product overview by GeekyAnts, which outlines how shared context, connected business tools, and controlled agent actions can support everyday workflows.

Its product overview describes a shared foundation connecting people, organizational knowledge, business applications, and AI agents on infrastructure the organization controls. Instead of treating each assistant as an isolated tool, the approach brings access, context, and workflow execution into a common architecture.

What sits underneath the assistants?

According to the overview, the foundation includes:

AI models and a gateway for access, routing, and usage.
Connections to approved business tools that provide context and support workflows.
An agent runtime that coordinates the steps needed to complete work.
Shared memory that keeps knowledge connected to its sources.
Guardrails, audit trails, and human approvals governing access and agent actions.

Personal assistants, team assistants, and custom agents can then operate across meetings, messages, projects, email, and documents.

The scenarios below illustrate how that architecture could be applied. They are potential implementations, rather than verified deployments or a list of ready-made integrations.

1. Turning meeting decisions into reviewable tasks

A product meeting ends with a decision to change an onboarding flow. The discussion contains useful context, but someone still needs to translate it into a task.

An assistant could identify the proposed action, retrieve the relevant project context, and prepare a task draft for review.

A useful draft would include:

The decision and its source.
The proposed scope of work.
An owner and deadline, when explicitly agreed.
Questions that remain unresolved.

Where it helps: Teams that repeatedly lose decisions between meetings and project trackers.

Implementation consideration: A suggestion should not automatically become a commitment. If the meeting does not establish an owner or deadline, the assistant should flag the gap rather than invent one.

2. Surfacing project blockers across tools

A blocker may appear in a message thread while the corresponding task still looks healthy in the project tracker.

A team assistant could combine permitted project information with related discussions to prepare a blocker summary. For example, it might identify that a release depends on an API change awaiting review.

The useful output would explain the dependency and link to supporting evidence.

Where it helps: Projects where status information is distributed across conversations, documents, and task systems.

Implementation consideration: Conflicting or outdated information needs to remain visible. A stale message should not silently override a newer project update.

3. Preparing follow-ups for human approval

Follow-ups often require reconstructing context from several places: a meeting, an email thread, and a project update.

An agent could gather the relevant information and prepare a draft containing agreed actions, open questions, and next steps. A person would review the content before it is sent.

Where it helps: Customer delivery, vendor coordination, and internal project communication.

Implementation consideration: Drafting and sending should have separate permissions. Approval should apply to the specific message and recipients, particularly when the draft includes sensitive information.

4. Answering internal questions with source context

Questions such as “Why was this integration postponed?” often require searching through multiple conversations and documents.

AntFabric’s described shared memory could support an assistant that retrieves relevant knowledge and connects its answer to the underlying sources.

For engineering teams, this could help with onboarding, understanding earlier architecture decisions, or locating project context.

Where it helps: Organizations where useful knowledge exists but is difficult to find or understand.

Implementation consideration: Shared memory needs permission boundaries and a way to handle changed or deleted information. An assistant should distinguish a documented decision from its own interpretation.

5. Coordinating a workflow across applications

Some operations involve several tools and a sequence of dependent steps.

Consider a hypothetical change-request workflow. An assistant could gather the request, locate relevant documentation, prepare an impact summary, and draft the next task. A reviewer would approve the proposed action before the workflow proceeds.

The agent runtime described in the overview provides the coordination layer for this kind of work. The exact integrations and behavior would depend on the implementation.

Where it helps: Repeated processes where employees manually move context between applications.

Implementation consideration: Partial failures matter. If one step succeeds and the next fails, the workflow needs a clear recovery path that avoids duplicate tasks or repeated notifications.

How an engineering team could evaluate the approach

A useful pilot would focus on one operation with a clear starting point and a reviewable result. Meeting-to-task drafting is one example.

Before implementation, the team should define the permitted sources, available actions, approval requirements, and conditions that require human intervention.

Evaluation could then track:

How often reviewers accept drafts without major corrections.
Whether outputs reference the correct sources.
How much time the workflow saves after review effort.
Whether access restrictions hold during testing.
How reliably the system handles missing context and failed actions.

The overview does not specify supported connectors, deployment configurations, memory implementation, or runtime guarantees. Those details would need technical validation before production use.

AntFabric’s proposed approach is most relevant when an organization needs assistants to work across systems with shared context and controlled actions. The practical starting point is one workflow where the result can be checked, corrected, and measured.

Building Reliable Workforce Apps: Lessons From ShiftPilot and Three Companies to Evaluate

Harsha — Fri, 09 Oct 2026 06:58:42 +0000

A shift-management app becomes difficult to engineer when a single action affects scheduling, payroll, notifications, and an external reporting system.

A failed request creates an uncomfortable question: did the operation fail, or did its confirmation simply never arrive?

GeekyAnts’ published ShiftPilot workforce management case study provides a useful starting point. The engagement strengthened an existing Flutter and Firebase application, covering recurring schedules, worker validation, payroll, and Belgian DIMONA employment declarations.

The practical lessons concern how teams model failure, preserve existing functionality, and evaluate engineering partners.

Why Should Retries Be Part of the Architecture?

The case study describes Cloud Tasks and Firestore state management supporting retries and recovery, with idempotency controls intended to prevent duplicate declarations.

For similar applications, an architecture review should distinguish between a failed operation and an unknown outcome.

Consider a hypothetical submission that reaches an external service just before the connection drops. Automatically creating another submission could duplicate the original action. Treating it as completed could conceal a genuine failure.

Useful review questions include:

What identifies the original business operation across retries?
Where is its latest confirmed status stored?
How are uncertain outcomes investigated?
When does automated recovery stop and human review begin?

These are proposed evaluation questions, not a description of ShiftPilot’s internal implementation.

What Should Be Tested Beyond the Happy Path?

ShiftPilot’s published challenges include unreliable venue connectivity, long shifts, and time-zone-sensitive scheduling.

Those constraints suggest several useful test scenarios for workforce products:

Scenario	Behavior to verify
Connection drops after submission	The interface distinguishes pending confirmation from confirmed failure
The same action is submitted twice	Duplicate processing is detected or safely prevented
A shift crosses a daylight-saving change	Duration follows the agreed scheduling and payroll rules
A background task repeatedly fails	An operator can identify the failure and its recovery path

A successful screen interaction is only one part of acceptance. The associated business operation needs an observable, explainable outcome.

Does Modernization Require a New Backend?

In this engagement, GeekyAnts extended the existing Flutter and Firebase architecture rather than introducing another backend stack. The case study also describes stronger review, staging, and release controls.

For another product, the same decision should follow an assessment of its actual constraints. Teams can ask whether the current stack prevents a required capability or whether unclear workflow ownership, insufficient testing, or weak recovery mechanisms cause the problem.

That distinction helps define a modernization scope before committing to a replacement.

Which Companies Could Teams Evaluate?

The following companies offer relevant engineering services. This is a capability-based shortlist, not a verified performance ranking or a claim that all three have equivalent workforce-platform experience.

1. GeekyAnts

GeekyAnts provides the directly relevant ShiftPilot example discussed here. Evaluation should examine its proposed responsibilities for mobile workflows, integrations, failure recovery, and ongoing support. The published case study does not provide independently verified reliability benchmarks.

2. thoughtbot

thoughtbot offers mobile product design and development. It is a candidate for teams evaluating application workflows and mobile experiences. Buyers should separately establish experience with payroll integrations, scheduling rules, and operational recovery.

3. 10Pearls

10Pearls offers application modernization and enterprise application development. Its services make it relevant to evaluations involving existing systems and integration work. A proposal should clarify migration scope, testing responsibilities, and support after release.

What Evidence Should Decide the Choice?

Each candidate should work through the same failure scenario: an operation reaches an external system, its acknowledgement disappears, and the user retries.

The explanation should identify persisted state, duplicate handling, operator visibility, and recovery ownership. That discussion offers a concrete way to assess engineering judgment beyond a technology checklist.

Which failure scenario has been hardest to handle in a scheduling or workforce application?

Why Developer Communities Still Matter: Lessons From ReactPlay and Five Companies Supporting Open Source

Harsha — Fri, 09 Oct 2026 05:37:49 +0000

AI can help generate a component or explain unfamiliar code. Working with other developers introduces a different challenge: explaining decisions, responding to feedback, and contributing to something that already exists.

That distinction runs through a ReactPlay meetup transcript featuring community organizers and GeekyAnts co-founder Sanket Sahu.

The discussion covers open-source participation, local meetups, and the importance of bringing technical communities beyond established technology hubs. Its most useful lesson is practical: a developer community becomes valuable when attendance leads to participation.

What Can Developers Learn From ReactPlay’s Community Model?

The organizers describe ReactPlay as both an open-source project and a community with online discussions and offline chapters.

Its platform allows developers to create small projects called “plays.” Participants can contribute to the platform itself or build something within it.

This offers a manageable starting point. Contributing does not have to begin with a major architectural change. A small project can introduce the habits required for collaborative development: understanding existing conventions, documenting behavior, and making changes that someone else can review.

The transcript also describes a connection between these activities. One organizer became involved through repository contributions and a hackathon before taking on broader community responsibilities.

The original discussion offers useful context on how ReactPlay connects open-source projects with local developer communities.

Why Does Open Source Still Matter When AI Can Write Code?

The speakers raise the continued relevance of open source in the AI era, although the transcript does not explore the argument in detail.

A practical extension of that point is that generating code and contributing code require different kinds of work.

A contribution must fit an existing project. It may need tests, documentation, compatibility checks, and an explanation of why the change belongs there.

For example, a proposed fix for a React component might appear correct in isolation but change keyboard behavior or break an existing usage pattern. Reviewing that change requires understanding the surrounding system.

AI assistance does not remove those responsibilities. The contributor still needs to understand the patch, verify its behavior, and follow the repository’s contribution policies.

For learners, that makes open source a useful setting for developing judgment alongside implementation skills.

How Can Meetups Lead to More Useful Technical Collaboration?

The organizers encourage attendees to speak with people beyond the friends they arrived with and to approach conversations respectfully.

One anecdote describes an attendee developing a product idea after meeting someone at an earlier event. It illustrates a possible outcome, rather than a promise that networking automatically creates opportunities.

A practical approach is to bring a specific question.

A developer investigating slow list rendering, for example, can explain the dataset, the observed behavior, and the approaches already tested. That gives other participants something concrete to discuss.

Following up with a small reproduction, an issue, or a short write-up can turn an event conversation into shared technical work.

Why Should Developer Communities Extend Beyond Major Cities?

The transcript discusses chapters in Bengaluru, Kolkata, and Siliguri, alongside an initiative called West Bengal Tech.

The speakers identify a gap between enthusiasm and access. Developers outside established technology hubs may have the motivation to learn but fewer opportunities to meet experienced practitioners.

A useful local community does not need to begin with a large conference. A recurring project demonstration, repository walkthrough, or debugging session can provide a starting point.

Consistency matters. Participants need a clear way to return, ask questions, and gradually take responsibility for activities themselves.

Which Five Companies Offer Useful Examples of Developer Ecosystem Support?

The following companies provide different examples through public tooling or community involvement. This is an editorial selection, not a measured ranking of company performance.

1. GeekyAnts: UI Tooling and Community Participation

In the transcript, ReactPlay’s organizers identify GeekyAnts as the venue for their first meetup and the event being discussed. Sanket Sahu also describes the company’s involvement in developer events and open-source UI libraries.

One concrete project developers can inspect is gluestack-ui, which provides components and patterns for React and React Native.

Its relevance here is the connection between shared tooling and opportunities to discuss implementation. Developers evaluating the project should examine its documentation, contribution process, and suitability for their application.

2. Microsoft: Developer Tooling Through VS Code

Microsoft’s provides a public codebase for a widely used development environment.

For developers interested in tooling, a useful exercise is to follow a narrowly scoped issue through discussion, implementation, and testing. The learning opportunity includes how changes are explained and reviewed, not just the final code.

3. Vercel: Framework Development Through Next.js

Vercel’s offers a public entry point into a React framework.

Developers can use it to investigate how framework behavior connects to application-level problems. A focused bug reproduction or documentation clarification can be more useful than an ambitious change without a clearly established need.

4. Shopify: React Native Tooling Through FlashList

Shopify’s focuses on list rendering in React Native.

It provides a specific technical subject for community learning. Developers can examine rendering behavior, construct representative examples, and discuss performance using reproducible evidence rather than broad claims.

5. Harness: Open Development Infrastructure

Harness Open Source includes code hosting, CI/CD pipelines, development environments, and artifact registries.

It broadens the discussion beyond interface development. Developers interested in delivery systems can explore how source changes move through build and release workflows.

What Makes Participation Worthwhile?

The strongest next step is small enough to finish: reproduce one bug, clarify one setup instruction, or explain one project decision.

A useful contribution leaves another developer with less uncertainty. A useful meetup creates the conditions for that work to begin.

The ReactPlay discussion shows how repositories, events, and regional communities can connect. Their lasting value depends on what participants build, explain, and maintain together.

Core Banking Modernization: Engineering Trade-offs and 5 Companies to Evaluate

Harsha — Thu, 24 Sep 2026 09:54:32 +0000

Modernizing a banking platform means changing systems while customers continue making payments, checking balances, and completing onboarding. A migration can deliver new functionality while still failing operationally if transactions become inconsistent or incidents become harder to diagnose.

The GeekyAnts video Modernizing Core Banking Without Downtime discusses phased migrations, payment orchestration, mobile security, and observability. This article uses its transcript as a starting point and examines the engineering questions behind those approaches.

What Does Phased Modernization Actually Require?

The transcript describes a strangler fig approach: gradually replacing legacy functionality while the existing system continues operating.

For example, a bank could introduce a new onboarding service while retaining its existing account ledger. Subsequent stages might replace other capabilities once their dependencies and behavior are understood.

The difficult part is managing the transition between systems. Teams need clear answers to questions such as:

Which system owns each piece of data during migration?
How are requests routed between old and new services?
How are incomplete or duplicated operations detected?
What happens to transactions already in progress during a rollback?

A phased approach limits the scope of each change. It still requires testing, reconciliation, and explicit recovery procedures.

Payment Orchestration Needs More Than Gateway Routing

The video also highlights multi-gateway payment orchestration.

Routing payments through different providers can offer operational flexibility, but a timeout creates an important ambiguity: the provider may have processed the payment even though the application did not receive confirmation.

Immediately retrying through another gateway could create a duplicate charge.

A design review should therefore examine idempotency, transaction status tracking, reconciliation, and provider-specific failure behavior. Gateway availability alone does not establish whether a payment completed correctly.

Useful test scenarios include delayed callbacks, repeated notifications, and a provider recovering after the application has marked an operation as pending.

Mobile Security and Observability Need Operational Planning

The transcript mentions React Native and Flutter applications alongside runtime application self-protection, SIM binding, and certificate pinning.

These controls address different concerns and need individual evaluation. For example, certificate pinning requires a certificate rotation and recovery plan. Device or SIM-related checks require account recovery paths for legitimate users who change devices.

Framework selection does not establish the security of the finished application. Teams still need to examine authentication, authorization, sensitive-data handling, and backend behavior.

Observability also needs to follow business operations across services. When onboarding fails, engineers should be able to determine whether the problem originated in identity verification, application logic, or a downstream dependency.

The goal is actionable diagnostic information without unnecessarily exposing sensitive customer data.

Five Companies to Evaluate for Banking Modernization

The following companies offer relevant services across banking modernization and financial application development. The numbering organizes the shortlist; it does not represent a verified performance ranking.

1. GeekyAnts

The source video describes phased legacy migration, payment orchestration, and cross-platform mobile engineering.

Those areas are relevant to institutions updating digital channels and their supporting services. An assessment should request comparable project evidence and clarify whether the proposed work includes core transaction systems, surrounding applications, or both.

Evaluation focus: Migration boundaries, transaction reconciliation, rollback procedures, and operational ownership.

2. IBM Consulting

IBM’s financial services practice covers core banking, payments, and cloud transformation.

Its published scope is relevant to institutions evaluating changes across established enterprise systems. Project assessment should identify the specific platforms, dependencies, and delivery responsibilities involved.

Evaluation focus: Legacy integration, migration sequencing, and the proposed team’s experience with comparable banking environments.

3. Dev Technosys

Dev Technosys’ fintech development services are relevant to financial applications and customer-facing experiences.

Application development and core banking migration involve different responsibilities. Institutions should verify experience with the particular systems being changed rather than treating fintech development as evidence of core migration expertise.

Evaluation focus: Backend integration, transaction handling, security testing, and maintenance responsibilities.

4. EPAM

EPAM’s financial services modernization offering with AWS covers cloud and data modernization.

Those capabilities are relevant when a banking program includes infrastructure changes and updates to supporting data systems.

Evaluation focus: Data consistency, production migration experience, and how application and infrastructure changes are coordinated.

5. Globant

Globant’s financial services offerings cover digital transformation and technology integration.

That scope is relevant to programs connecting financial products with existing systems. Evaluation should distinguish improvements to customer journeys from changes to the underlying transaction infrastructure.

Evaluation focus: Integration boundaries, measurable acceptance criteria, and support after deployment.

What Evidence Should Guide the Decision?

The transcript reports transaction-volume, availability, KYC, and latency outcomes. It does not provide enough implementation detail to establish how those results were measured or whether another institution would achieve similar outcomes.

Availability figures also do not, by themselves, demonstrate that a particular migration caused no downtime.

A useful technical assessment should request a representative migration plan, failure scenarios, reconciliation checks, and a demonstrated recovery process. Those artifacts make the proposal easier to evaluate than broad assurances about seamless modernization.

For developers working on financial systems: which has proved hardest to manage during a migration—data ownership, payment reconciliation, or rollback?

Architecture Before Infrastructure: 5 Companies to Evaluate for Backend Modernization

Harsha — Thu, 24 Sep 2026 06:06:41 +0000

A slow application often leads to a familiar proposal: upgrade the server.

Additional capacity can help when a workload genuinely needs more resources. But an infrastructure upgrade should follow a diagnosis. Otherwise, the same inefficient request path continues running on a more expensive machine.

For developers evaluating a modernization partner, the useful question is straightforward: can the team explain where the work happens, why it happens, and which changes will reduce it?

What a Smaller Server Revealed

GeekyAnts’ article on why bigger servers don’t fix bad architecture describes an application that became unstable after moving from a 64 GB server to a 2 GB instance, despite having only four or five active users.

Its stack included Hasura, Node.js, PostgreSQL, and Dockerized services. Some requests travelled from Hasura to Node.js and back through Hasura before reaching PostgreSQL.

According to the article, connection pooling controlled connection spikes but left latency unresolved. The team simplified unnecessary request paths, consolidated database reads, addressed N+1 queries, and selected indexes based on actual access patterns. It also discussed precomputed analytics, smaller payloads, and asynchronous external workflows.

These observations provide useful diagnostic ideas. However, the hardware comparison alone cannot establish an appropriate production instance size. Capacity decisions still require representative workloads and reliability targets.

The Engineering Lesson: Measure Work Per Request

A useful extension of this case is to examine the cost of a single user action.

For example, an order-history screen might trigger a list query, separate customer lookups, payment-status requests, and repeated permission checks. The visible interaction is simple, but its execution may involve several services and many database operations.

Before changing infrastructure, an engineering team can establish:

Measurement	What it helps reveal
Database queries per request	Repeated reads and query fan-out
Connection acquisition time	Pool contention or connection limits
Distributed trace duration	Time spent in each dependency
p95 and p99 response times	Slow requests hidden by averages
CPU, memory, and I/O saturation	Actual resource constraints
Cost per successful transaction	Whether spending tracks useful output

These measurements help separate architectural overhead from genuine capacity pressure.

Simplification Still Needs Boundaries

Removing an intermediate service is not automatically an improvement.

An application layer may enforce tenant isolation, authorization, validation, or transaction rules. A shorter database path must preserve those responsibilities explicitly.

Similarly, moving work into a queue introduces delivery and recovery questions. What happens if a message is processed twice? How does the system recover when a worker fails? How long can completion be delayed?

Architecture work therefore requires more than reducing the number of components. Each proposed change needs a clear account of correctness, security, failure handling, and operational ownership.

Five Companies Worth Evaluating

The following companies have published engineering material or service offerings relevant to backend modernization, cloud optimization, or architecture improvement. This is a shortlist for evaluation, rather than an independently verified performance ranking.

1. GeekyAnts

GeekyAnts is relevant to this discussion because the source article presents a concrete investigation involving Hasura, Node.js, and PostgreSQL.

Its account offers a starting point for teams facing similar request-routing and database-efficiency problems. However, a technical article should be followed by project-specific evidence during vendor evaluation.

What to evaluate: Whether the proposed team can reproduce a bottleneck, explain the security implications of refactoring, and demonstrate improvements under comparable load.

2. Thoughtworks

Thoughtworks legacy modernization services cover enterprise, product, data-platform, and mainframe modernization. Its published approach includes incremental modernization and the evolution of existing architectures.

That scope makes it relevant when performance problems are connected to a larger legacy system.

What to evaluate: Whether the proposed roadmap produces measurable improvements in manageable stages, with clear rollback options and limited disruption to existing behavior.

3. EPAM

EPAM’s modernization offering includes architecture design, platform engineering, API enablement, and in-place optimization.

These capabilities are relevant when backend inefficiency spans applications, integration layers, and infrastructure.

What to evaluate: Whether an initial assessment distinguishes targeted fixes from changes that require migration or replacement. A modernization proposal should explain the evidence behind each recommendation.

4. Equal Experts

Equal Experts describes modernisation and platform services covering incremental system improvement, architecture modernization, and cloud optimization. Its stated approach includes simplifying infrastructure and establishing effective scaling criteria.

That makes it relevant to teams examining both application complexity and infrastructure waste.

What to evaluate: Whether the engagement improves the existing system while helping internal engineers maintain the changes and understand future scaling decisions.

5. Globant

Globant’s CloudOps services include application modernization, cloud operations, site reliability engineering, and chaos engineering.

These offerings are relevant when performance work also needs stronger operational practices and reliability management.

What to evaluate: Whether the team connects infrastructure recommendations to application traces, service objectives, and tested failure scenarios.

A Practical Way to Compare Partners

A focused diagnostic engagement can provide better evidence than a broad transformation pitch.

Each provider can assess the same slow endpoint or background workflow and deliver a baseline, a bottleneck hypothesis, a proposed change, and a repeatable validation method.

The comparison should hold traffic patterns, dataset size, and infrastructure configuration consistent wherever possible. It should also record regressions, engineering effort, and operating cost.

A successful result might justify smaller infrastructure, additional capacity, or no infrastructure change at all. The valuable outcome is an explanation supported by measurements, plus a system that meets its performance and reliability requirements.

Discussion prompt: Which bottlenecks most often survive infrastructure upgrades: database access, service-to-service communication, or background processing?

AI Coding Agents Can See Mobile Apps Now , But How Fast Can They Learn?

Harsha — Fri, 11 Sep 2026 10:52:37 +0000

AI coding agents are changing how developers think about software development.

Earlier, AI tools were mainly used for generating code snippets or suggesting improvements.

Now, agents are moving toward a more interactive workflow:

Write → Run → Observe → Debug → Improve

For web applications, this feedback loop is already becoming fast and efficient.

Mobile development introduces a different challenge.

An AI agent may be able to write React Native code, but the real question is:

How quickly can it see the result of that change?

A mobile agent needs to:

Build the application
Launch a simulator or device
Inspect the UI
Understand errors
Make corrections
Repeat the process

The speed of this loop can determine how effective AI assistance becomes.

A key factor is the difference between JavaScript changes and native changes.

JavaScript updates can often use fast refresh and provide immediate feedback.

Native changes may require rebuilding the application, increasing the time between making a change and seeing the result.

This means React Native architecture decisions can influence not only performance and maintainability but also how well AI agents can work with the codebase.

What makes an app easier for AI agents to understand?

For AI-assisted development, applications need to be easier to inspect.

Some important practices include:

Clear component structures
Meaningful accessibility labels
Stable identifiers
Predictable application states
Well-defined native boundaries

An agent does not only need access to the code.

It needs context about how the application behaves.

Companies exploring AI and mobile development workflows

Several companies are working on AI-powered software development, mobile engineering, and developer productivity:

1. Microsoft
Building AI-powered developer tools and enterprise coding workflows.

2. Google
Developing AI capabilities across developer tools, cloud platforms, and application development.

3. Amazon Web Services (AWS)
Providing infrastructure and AI services for building intelligent applications.

4. GitHub
Focused on AI-assisted development through tools like Copilot.

5. Callstack
Known for React Native expertise and work around improving mobile development workflows.

6. Thoughtworks
Exploring modern software engineering approaches, including AI-assisted development practices.

7. GeekyAnts
Working across React Native development, AI-powered product engineering, and exploring how agent-driven workflows can improve mobile application development.

The future of AI-assisted mobile development

The biggest advantage of AI coding agents may not come from generating code faster.

It may come from reducing the time between:

"I changed something"

and

"I know whether it worked."

The teams that benefit most from AI agents will likely be the ones building applications that are easier to understand, test, and iterate on.

The future question may not be:

"Can AI write mobile apps?"

It may be:

"How quickly can AI understand, test, and improve the apps we already build?"

Reference discussion:
https://geekyants.com/blog/the-agent-can-see-your-app-how-often-can-it-look

AI Agents in React Native: Why Feedback Speed Matters and Five Companies to Watch

Harsha — Fri, 11 Sep 2026 05:35:06 +0000

An AI coding agent can generate a screen quickly. The harder question is how quickly it can discover that the screen behaves incorrectly.

For React Native teams, that delay deserves attention. Code generation is only one part of a workflow that also includes execution, inspection, and correction.

This article builds on Sakshya Arora’s analysis of mobile agent feedback loops, published by GeekyAnts, and examines five companies with relevant engineering services or tooling.

What Determines How Quickly an Agent Can Improve an App?

The source article identifies an important architectural distinction: JavaScript changes can often remain within the refresh cycle, while changes to native code, dependencies, or build configuration can require recompilation.

It also highlights interface semantics, predictable launch states, and real-device validation. An agent needs recognizable elements and repeatable conditions to inspect changes effectively. A simulator screenshot alone cannot establish product quality.

The article’s timing examples are illustrative, rather than universal benchmarks. Its practical recommendation is to measure the actual repository before estimating productivity gains.

Fast Refresh Helps, but Its Behavior Matters

React Native’s Fast Refresh documentation explains that many component edits can appear within seconds. However, refresh behavior depends on module structure. Some changes trigger broader updates or a full reload, and local state is not always preserved.

That introduces an evaluation concern: a visually correct result may depend on state left over from an earlier attempt.

A useful verification process should therefore distinguish between checking an edit in the current session and checking the same behavior after a fresh launch. Both provide evidence, but they answer different questions.

Five Companies Relevant to AI-Assisted Mobile Development

These companies address different parts of the workflow. The selection reflects documented relevance, not a measured ranking of delivery quality or AI productivity.

1. Custom Engineering and Integration

GeekyAnts describes services covering agent architecture, enterprise integration, validation, access controls, and monitoring. Its AI agent development offering is relevant to teams considering custom automation around existing engineering systems.

For a mobile engagement, the useful assessment would be a repository-specific demonstration: whether the implementation connects code changes to executable checks and reviewable results. A broad service description does not establish a particular improvement in mobile iteration time.

2. React Native Guidance for Coding Agents

Callstack publishes structured React Native best practices for AI agents. Its guidance covers JavaScript, native performance, and bundling, with steps, prerequisites, pitfalls, and verification advice.

This addresses the quality of an agent’s decisions. Access to a running application is more valuable when the agent also has framework-specific guidance for interpreting problems.

The limitation is straightforward: written practices still require execution and measurement in the target project.

3. Development Builds and Native Configuration

Expo provides development builds that accommodate custom native libraries and configuration. Its development-build documentation distinguishes JavaScript iteration from changes that require an updated native build.

For teams designing agent workflows, that distinction can inform when automation should reuse an installed application and when it should rebuild.

Expo’s tooling helps organize this process, but native changes still carry compilation costs. Build setup should reflect the project’s dependencies and platform requirements.

4. Tools for Apple-Platform Agents

Sentry’s XcodeBuildMCP project provides an MCP server and CLI for agents working with iOS and macOS projects. Its repository documents build and test commands, debugging support, and log capture.

This makes it relevant to teams connecting an agent with Apple development tooling.

Operational requirements remain significant: compatible macOS and Xcode installations, configured projects, and code signing where required. Android workflows need separate coverage.

5. Automated Testing on Physical Devices

BrowserStack offers App Automate for automated application testing on real mobile devices.

Its role fits a later verification stage: checking behavior across selected device and operating-system combinations after a change is ready for broader testing.

A sensible evaluation would consider device coverage, diagnostic evidence, and execution time. Remote device testing serves a different purpose from rapid local editing, so teams should measure each stage separately.

What Should Teams Measure?

An evaluation can track:

Time from an edit to an inspectable application state.
Time spent waiting for builds, devices, or test execution.
Percentage of attempted fixes that satisfy predefined acceptance criteria.
Human review time needed before accepting a change.

These measurements prevent a misleading outcome: an agent producing more patches while engineers spend longer validating them.

The meaningful target is a shorter path from a reported problem to an accepted fix. Company selection and tooling choices should follow whichever part of that path is actually slowing the team down.

What Does a Clutch Global Award Actually Tell You About a Software Development Company?

Harsha — Thu, 27 Aug 2026 10:26:27 +0000

Awards in software development are useful, but I don’t think they should ever be the main reason to choose an engineering partner.

GeekyAnts was recently named a Summer 2026 Clutch Global Award winner. Clutch recognized more than 400 companies across 54 IT and development categories, using its Ability to Deliver methodology, which considers verified client feedback, project success, industry expertise, and market presence.

What I find more useful is looking at what sits behind the recognition.

GeekyAnts works 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 and currently holds a 4.8 rating from 116 Clutch reviews.

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

From a developer’s perspective, though, I’d still evaluate an engineering company on things such as:

Relevant production projects
Seniority of the actual delivery team
Architecture and modernization experience
How it handles technical debt
Production AI experience versus demos
Communication after development begins

An award can help create the shortlist. It shouldn’t finish the evaluation.

Curious how others approach this: do third-party awards and Clutch reviews influence which development companies you consider, or do you mostly rely on case studies and technical interviews?

Your Company Has the Data. Why Does Getting an Answer Still Require a Ticket?

Harsha — Thu, 27 Aug 2026 05:35:38 +0000

Most enterprise teams are not short on data.

They have CRMs, ERPs, finance systems, data warehouses, HR platforms, project management tools, and operational databases.

But ask a seemingly simple question like:

Which customer accounts saw the largest drop in revenue this quarter compared with the previous quarter?

And suddenly a workflow begins.

Someone sends a message to the data team. An analyst figures out which tables contain the right information. They write SQL, validate the query, export the result, create a chart, and send it back.

Then comes the follow-up:

What about enterprise customers only?

Another request. Another query.

This is one reason self-service analytics still does not feel very self-service.

The Problem Is Not Data Access

Giving every business user direct database access would technically remove the reporting queue.

It would also create a new set of problems.

Users may:

Query the wrong tables
Use inconsistent metric definitions
Accidentally expose sensitive information
Run expensive queries against production systems
Misinterpret database relationships
Produce conflicting answers to the same business question

Traditional dashboards solve part of this problem by restricting what users can see.

But dashboards have another limitation: somebody has to anticipate the question before building the dashboard.

That works well for standard KPIs.

It works less well when someone wants to ask:

Why did support resolution time increase last month?

Then:

Which regions contributed most?

Then:

Was the increase concentrated among any particular customer segment?

This is where conversational data intelligence becomes interesting.

What If Business Users Could Ask the Database Questions?

The basic idea sounds straightforward:

Business question
      ↓
Natural language
      ↓
Generate SQL
      ↓
Run SQL
      ↓
Return answer

But using an LLM to generate SQL and immediately executing it against an enterprise database would be risky.

A production architecture needs several controls between "generate SQL" and "execute SQL."

A safer workflow looks more like:

User Question
      ↓
Identity + Permissions
      ↓
Retrieve Approved Schema Context
      ↓
Generate SQL
      ↓
Validate Query
      ↓
Security / Cost Checks
      ↓
Read-Only Execution
      ↓
Chart / Table / Answer
      ↓
Audit Log

This is the approach behind the GeekyAnts Conversational Data Intelligence Accelerator. It converts natural-language questions into SQL using approved schemas and business context, validates the generated query, and executes approved queries against read-only data sources. Results can then be returned as charts, tables, HTML, or JSON.

The interesting part is not simply "chat with your database."

It is chat with your database without throwing governance away.

Why Schema Context Matters

Consider this request:

Show me churn by customer segment.

A model cannot reliably answer that question just because it knows SQL.

It needs to understand what customer, segment, and churn mean inside that specific organization.

Maybe customer information exists in:

customer_accounts

while segments live in:

account_classification

and churn is not actually stored as a column at all.

Instead, the company may define churn as:

subscription_status = cancelled
AND
previous_status = active

That business context matters as much as SQL generation.

A conversational analytics system therefore needs curated schemas, table descriptions, column definitions, approved terminology, and metric definitions.

The accelerator uses this kind of metadata layer so the model can work with approved database context rather than treating every available table as equally valid.

SQL Generation Should Not Be a Single-Agent Problem

Another useful architectural idea is separating responsibilities.

Instead of trusting one LLM response from beginning to end, different stages can handle:

Schema understanding
SQL generation
SQL validation
Query execution
Result formatting

The current accelerator uses separate agent workflows around schema preparation, SQL generation, validation, and execution. It also supports checks such as dry runs, prohibited-operation detection, performance validation, and PostgreSQL EXPLAIN analysis.

This matters because an LLM generating syntactically valid SQL does not mean the SQL is safe, efficient, or semantically correct.

Where Does Conversational BI Actually Help?

The strongest use cases are not necessarily complicated machine-learning problems.

They are often repetitive questions currently taking analysts away from higher-value work.

Finance

Instead of requesting another spreadsheet, finance leaders could ask:

Why is operating expense above plan this month?

Followed by:

Which cost centers explain most of the variance?

The system can query approved finance data while retaining the company's agreed definitions.

Sales and Revenue

A revenue leader might ask:

Which opportunities scheduled to close this quarter have the highest slippage risk?

Then immediately investigate a region, sales team, account category, or product line.

Customer Support

Operational teams could investigate:

Which issue categories are driving our SLA breaches?

They can then explore resolution times, escalation patterns, backlogs, and customer impact without waiting for another dashboard.

Manufacturing and Supply Chain

Teams can explore questions around:

Stock-outs
Procurement variance
Lead times
Machine downtime
Defects
Production throughput
Shift performance

SaaS Products

Product and growth teams could investigate usage, revenue, churn, funnel conversion, support activity, reliability, and account health through natural-language questions.

Healthcare and Other Regulated Environments

Conversational analytics can also help users explore approved operational datasets such as capacity, utilization, claims, billing exceptions, or patient flow while applying role-aware access controls.

These are among the enterprise workflows the accelerator is designed to support.

Governance Is What Separates a Demo From a Real System

Building a natural-language-to-SQL demo is relatively easy now.

Building one that an enterprise data team is comfortable deploying is harder.

Production systems need controls around:

Read-only access

The AI should not suddenly decide to run:

DELETE FROM customers;

Schema allowlisting

Not every table or column should automatically become available to every user.

Identity and permissions

A CFO, regional sales manager, HR employee, and customer-support agent should not receive identical access.

Query validation

Generated SQL should be inspected before execution.

Performance limits

A technically valid query can still consume enormous database resources.

Auditability

Teams should be able to trace:

User Question → Generated SQL → Execution → Result

That becomes particularly important when an answer influences financial, operational, or compliance decisions.

This Should Reduce Data-Team Work, Not Replace Data Teams

There is an important distinction here.

Conversational BI should not try to automate every analytics problem.

Questions involving ambiguous business logic, complex statistical analysis, new data models, causal analysis, or strategic interpretation still need experienced analysts and data engineers.

The better target is the repetitive reporting queue.

The GeekyAnts proof of concept currently reports 1 to 5 minutes for suitable routine questions, compared with 30 to 60 minutes of manual analyst effort for comparable requests. Those are POC figures rather than a guarantee for every enterprise environment, but they illustrate where the opportunity lies.

Freeing analysts from routine SQL requests means they can spend more time on the problems where their expertise actually matters.

The Bigger Shift: From Dashboards to Questions

Dashboards are not going away.

Neither is SQL.

But the interface between business users and enterprise data is changing.

For years, organizations have required users to understand the reporting structure created for them.

Conversational analytics reverses that relationship.

The user asks:

What changed?

The system figures out how to query the approved data.

The user follows with:

Why?

Then:

Where is it happening?

And:

What should I investigate next?

The challenge is no longer just generating SQL from English.

The real engineering problem is building a system where natural-language questions can become trustworthy database queries without sacrificing security, performance, consistency, or auditability.

That is a much more interesting problem to solve.

If you're exploring how governed natural-language analytics could work against existing enterprise databases, the GeekyAnts Conversational Data Intelligence Accelerator provides one implementation approach:

Explore the Conversational Data Intelligence Accelerator