Web application development by an AI-assisted engineering team
GegoSoft builds custom web applications from Madurai, India — admin systems, SaaS products, portals and internal tools. We're unusual in one respect: we run six production products of our own, so most projects start from working code rather than an empty repository. That, plus every engineer using Claude Code daily, is why our timelines look the way they do.
Last reviewed: September 2026
- Who we are
- GegoSoft Technologies (OPC) Private Limited, a software company in Madurai, Tamil Nadu, India, established 2017. Eighteen engineers, designers and specialists.
- What we build
- Custom web applications: SaaS products, admin and operations systems, customer portals, dashboards, marketplaces, configurators and internal business tools.
- Primary stack
- Laravel and NestJS on the backend, React, Next.js and Angular on the front end, MySQL, PostgreSQL and MongoDB for data, Flutter and Kotlin for the mobile side.
- Two starting points
- Extend one of our six production products, or build new on our internal SaaS libraries. Both are faster than starting from zero, and both end with you owning the source.
- How AI changes it
- All eighteen engineers use Claude Code daily for scaffolding, test generation, refactoring and review. Every line is owned by a named engineer. AI does not approve merges or deployments.
- Engagement models
- Fixed-scope projects, dedicated teams on monthly retainer, or engineers embedded into your existing team. Long-term clients in the US, Australia, Europe and Dubai.
Almost nobody should start from an empty repository
Authentication, roles and permissions, multi-tenancy, billing, audit logs, notifications, file handling, an admin panel — every business application needs these, and none of them are what makes your product different. We've written them already. Your budget goes to the part that's actually yours.
Extend one of our products
If your requirement overlaps with something we already run in production, we customise that instead of rebuilding it. You start with a system that handles the boring ninety percent on day one.
- GegoK12 — school ERP: admissions, attendance, fees, examinations, parent communication. Twenty-plus schools in production.
- ChurchCMS — membership, families, groups, events, contributions and communication.
- BOQ Manager — construction estimation, bills of quantity and project costing.
- ChemTracker — chemical inventory, labelling and safety compliance.
- eTender — tender publication, bidding, evaluation and award workflow.
- Daybook — daily transaction and cash-book recording, with an Android app.
Typical result: a working system for your organisation in weeks rather than months, with only your specific requirements built new.
Build new on our SaaS libraries
For genuinely novel products, we start from internal libraries built over eight years of SaaS work — the plumbing every product needs, already written, tested and used in production.
- Tenancy and roles — multi-tenant data separation, role and permission management, team invitations.
- Billing and subscriptions — plans, trials, upgrades, proration, invoices and dunning.
- Admin scaffolding — the operator panel nobody demos and everybody needs from week one.
- Audit and activity logs — who changed what, when, with a readable history.
- Notifications — email, in-app and webhook delivery with retry handling.
- Import, export and reporting — the requests that arrive one month after launch, every time.
Typical result: a testable MVP on real data in six to ten weeks, not a clickable prototype.
Every engineer here uses Claude Code, every day
Not a pilot, not one team. It's standard tooling across all eighteen engineers, and it changed what a given budget buys. The gain isn't typing speed — it's that the work teams normally skip when time is short now fits inside the estimate.
Tests get written, not deferred
Test suites are the first thing cut when a deadline tightens, and the reason maintenance costs rise later. Generating thorough coverage is now cheap enough that it stays in scope, which is what makes a system safe to change in year two.
Review happens before review
Every pull request is read for security, performance and edge cases before a human reviewer opens it. Our engineers spend their attention on design decisions rather than on catching a missing null check.
Refactoring stops being a luxury
Renaming a concept across two hundred files, extracting a service, or upgrading a framework version used to be deferred indefinitely. It now takes an afternoon, so the codebase you get in month twelve isn't worse than the one from month two.
Documentation actually exists
API docs, architecture notes and onboarding guides written alongside the code rather than promised at handover. It matters most on the day you bring the work in-house or hand it to someone else.
Where the line is: AI drafts, tests and reviews. It does not approve a merge, decide an architecture, or deploy to production. A named engineer owns every part of your system and can explain any line of it to you.
What we build most often
Business software rather than brochure websites. Systems that people log into and use for hours a day.
Admin & operations systems
The internal system your team runs the business on — records, workflow, approvals, permissions and reporting, built around how you actually work rather than a generic template.
SaaS products
Multi-tenant applications with subscription billing, self-service onboarding, plan limits and an operator console. Our most common engagement, and where the internal libraries pay off most.
Customer & partner portals
Self-service for the people outside your organisation — customers checking orders, partners submitting claims, suppliers updating stock. Usually the cheapest way to cut support load.
Marketplaces & commerce
Multi-vendor platforms, B2B catalogues with account pricing, and commerce systems that need more logic than an off-the-shelf cart can carry.
Configurators & quoting tools
Products with options, dependencies and rules — where a customer builds a specification and gets a price without your sales team rebuilding a spreadsheet each time.
Field & location applications
Tracking, routing, check-ins and geo-fencing for teams working away from a desk, with a mobile app where the browser isn't enough.
Collaboration & communication
Ticketing, helpdesk, internal messaging and CRM-style tools, including integration with the systems your team already lives in.
Calculators & assessment tools
ROI, savings, emissions and eligibility calculators that make a technical argument concrete — and capture a qualified lead while doing it.
Legacy application rescue
An application nobody wants to touch, on a framework version out of support. We document what it does, get it onto a current stack, and make it safe to change again.
What we build with, and when we choose it
These are the technologies our team works in daily, not a list of everything that exists. If your project needs something outside this, we'll say so rather than learn it on your budget.
| Layer | What we use | When we reach for it |
|---|---|---|
| BACKEND | ||
| Laravel (PHP) | Laravel · Livewire · Eloquent | Our default for business applications. Mature, fast to build in, and where most of our internal libraries live. |
| NestJS (Node) | NestJS · TypeScript · Express | When the API is the product, when real-time matters, or when the team wants one language across the stack. |
| FRONT END | ||
| React & Next.js | React · Next.js · TypeScript · Tailwind | Public-facing applications where server rendering and SEO matter, and complex interactive interfaces. |
| Angular | Angular · TypeScript · RxJS | Large enterprise applications, and teams already standardised on Angular. Used in production on our healthcare work. |
| Livewire | Livewire · Alpine.js · Tailwind | Form and table-heavy admin systems on Laravel, where a separate front-end application would be overhead. |
| DATA | ||
| Relational | MySQL · PostgreSQL | The default. Most business data is relational and benefits from constraints and transactions. |
| Document | MongoDB · Redis | Variable-shape documents, event data, caching and queues. |
| MOBILE & INFRASTRUCTURE | ||
| Mobile | Flutter · Kotlin | Three dedicated mobile developers. Flutter where one codebase serves both platforms; native where the hardware demands it. |
| Hosting & delivery | AWS · Google Cloud · Docker · CI pipelines | Deployed to whichever cloud you already use, with automated pipelines and monitoring from day one. |
| Open source integration | Dolibarr · Mautic | Where an established open-source ERP or marketing platform beats building from scratch — including custom modules. |
Three ways clients work with us
Four of our long-term clients have worked with us for years across changing project shapes. The engagement model usually changes over time, and that's fine — it shouldn't require a new contract negotiation each time.
- Fixed-scope project — defined deliverable, agreed price, agreed date. Best when the requirement is clear and the boundaries hold.
- Dedicated team — a named group of engineers on a monthly retainer, working your backlog. Best for ongoing product development where priorities shift.
- Team extension — our engineers working inside your process, your repository, your standups. Best when you have a team and need more of it.
In every model the code is yours, hosted where you choose, in your repository. No platform lock-in and no licensing arrangement you can't exit.
How a project runs
Working software on a staging URL early, because reading a specification tells you far less than using the thing.
Discovery and data model
What the system does, who uses it, what the entities are and how they relate. Most project failures start here rather than in the code, so we spend real time on it.
Scope, estimate and route
Whether to extend an existing product or build new, a fixed scope with a price, and the metrics we'll be judged on. Agreed in writing before work starts.
Interface design
Screens designed including the empty, error and loading states. Our UI/UX team works on this in parallel with backend foundations, not after them.
Build in two-week increments
Working software on a staging URL you can use at the end of every sprint. Tests and code review on every change, not a QA phase bolted on at the end.
Hardening
Security review, query profiling, load testing against your expected traffic, backup and recovery rehearsal, and monitoring configured before anyone depends on it.
Handover and support
Deployment, documentation, team training and full source in your repository. Then a support retainer, or a clean exit with everything you need to run it yourselves.
We run our own software, so we know what year three costs
Most agencies hand over at launch and never learn what happens next. We've maintained GegoK12 across twenty-plus schools since 2017, and ChurchCMS, BOQ Manager, ChemTracker, eTender and Daybook alongside it. Owning software teaches you things client projects don't: what breaks after two years, what support actually costs, and which shortcuts you pay for later. That's what we design against.
Frequently asked questions
How much does a custom web application cost?
How long does it take to build a web application?
What does "AI-assisted development" actually mean here?
Do we own the code?
Should we build on Laravel or Node?
Can you take over an existing application?
Do you work with clients in other time zones?
Can you provide engineers to work inside our team?
Looking for something more specific?
Laravel & TALL Stack development
If you already know the project is Laravel, that page covers our backend practice, the TALL stack and our open-source products in more depth.
Laravel developmentSaaS product development
Multi-tenancy, subscription billing, self-service onboarding and everything else specific to building a product you sell by subscription.
SaaS developmentMobile app development
Flutter and Kotlin apps built against the same backend, by three dedicated mobile developers on the same team.
Mobile developmentDescribe the problem, not the solution.
Tell us what the system has to do and who uses it. We'll tell you whether to build it new, extend something we already run, or not build it at all.