Every technology stack is a series of decisions made at a specific moment in time, with the information available at that moment. Looking back at 23 years of technology choices, I can see clearly which decisions were right, which were right for their era but became technical debt, and which we'd make differently now.
This isn't a history of technology. It's a record of what we actually built on, why we chose it, and what we learned from the transitions. If you're making technology decisions now — for a new product, for a modernisation project, for a team that needs to evolve its stack — maybe something in here is useful.
The eras — what we built on and when
2002
Foundation
Classic ASP + MS Access — the first cloud CRM
Classic ASP MS Access SOAP APIs IIS
The first application Infomaze delivered was a cloud CRM for a US client — built on Classic ASP with MS Access as the database. In 2002, this was a legitimate technology choice. The remarkable thing in retrospect isn't the technology — it's that we were building software accessible over the internet for clients in another country before anyone called it SaaS. The concept was ahead of the tooling. The first SOAP integration we built was in this era — connecting to a US banking system. SOAP was the only option that existed.
Lesson: The technology was basic. The concept was not. Being early on cloud delivery mattered more than which server-side scripting language we used.
2003
Microsoft era
ASP.NET begins — SQL Server replaces Access
ASP.NET 1.0 SQL Server 2000 C# Web Forms
The pilot training company project was our first serious ASP.NET build — a multi-role system managing student records, instructor schedules, aircraft availability, and certification tracking. ASP.NET 1.0 was young and rough but it was a significant step up from Classic ASP. SQL Server 2000 replaced MS Access as the database — a decision that held for almost a decade as we moved through SQL Server 2005, 2008, 2012, and beyond. We stayed in the Microsoft ecosystem for the server-side stack through multiple .NET versions because the clients we were serving ran Windows infrastructure and the tooling was genuinely strong.
Lesson: The database decision matters more than the framework decision. SQL Server has outlasted every framework we used on top of it. Choose the data layer carefully.
2005
SystemTask era
ASP.NET maturing — SystemTask for 7-Eleven, Walmart
ASP.NET 2.0 → 3.5 SQL Server 2005 Web Services AJAX
SystemTask — the field service platform that became ElementIQ — was built in this era. ASP.NET 2.0 brought membership providers, master pages, and a much more productive development experience. The client's roster (7-Eleven, JC Penney, Walmart, Pixel Magic) required the platform to handle real enterprise load and complex multi-client workflows. AJAX changed the user experience — suddenly we could update parts of a page without full reloads, which mattered enormously for a dispatching interface. We also began serious adoption of stored procedures and optimised SQL — the database performance habits that still inform how we approach data-heavy applications today.
Lesson: Enterprise load reveals assumptions in your architecture that smaller scale hides. SystemTask's architecture decisions from this era shaped three subsequent versions of the same platform.
2008
PHP + MVC era
PHP enters the stack — CakePHP, then CodeIgniter
PHP 5 CakePHP CodeIgniter MySQL ASP.NET MVC
The web was diversifying. PHP was increasingly dominant for web applications, particularly in the agency and startup world. We added PHP to the stack — initially CakePHP, then CodeIgniter — because clients were coming to us from ecosystems where PHP was the established choice and the talent pool was larger. ASP.NET MVC also launched and we adopted it quickly — it was a significant improvement over Web Forms for building maintainable server-side applications and aligned with the MVC patterns the industry was converging on. Running both stacks in parallel wasn't ideal, but it reflected the reality of serving clients across different ecosystems.
Lesson: Maintaining two parallel back-end stacks is expensive in knowledge and tooling. We learned to be explicit about which stack a project would use at the start — not mid-project.
2010
PrintPlanr era
Laravel arrives — REST APIs — PrintPlanr launches
Laravel (PHP) REST APIs MySQL ASP.NET MVC 4 jQuery
Laravel marked a meaningful evolution in PHP development, introducing cleaner syntax, the Eloquent ORM, Artisan CLI, and a more structured ecosystem. While we adopted Laravel for several web and application projects, our core product direction followed a different path.
During this same period, the industry was also transitioning from SOAP APIs to RESTful services—bringing greater simplicity, scalability, and developer efficiency.
It was in this phase that we identified a clear gap in the print industry: the absence of robust, cloud-based Print MIS solutions capable of handling real-world production workflows. Recognizing this opportunity, we conceived and built PrintPLANR as a cloud-native platform from the ground up. The decision to build it on the .NET stack was intentional, enabling us to design a scalable, secure, and performance-driven system tailored to the complex needs of print businesses.
Lesson: Framework choice should be driven by the problem context, deployment environment, and long-term product requirements—not just internal preference. We have leveraged Laravel where it made practical sense for web applications and rapid development needs. However, when building PrintPLANR as a SaaS-based platform requiring higher levels of scalability, security, and performance, we deliberately chose the .NET stack to support those demands effectively.
2015
Cloud + mobile era
Azure and AWS — Ionic mobile — Elasticsearch
Microsoft Azure AWS Ionic (mobile) Elasticsearch React (early)
Infrastructure moved to the cloud. Azure for Microsoft-ecosystem clients, AWS for others. The real estate platform with 42 million properties was built in this era — and it was Elasticsearch that made sub-1-second search across that dataset possible. Ionic was our first serious mobile framework — it allowed us to write once and deploy to iOS and Android, which was a significant productivity gain. The tradeoff was performance: Ionic's hybrid approach produced acceptable apps but not native-feeling ones. We also began early adoption of React for front-end components, initially alongside jQuery on the same pages.
Lesson: "Write once, deploy everywhere" is a tradeoff. Ionic gave us cross-platform reach but cost us native feel. When the user experience mattered enough, we rebuilt natively — which is why we moved to React Native.
2018
Modern stack
React Native replaces Ionic — Laravel primary — .NET current
React Native Laravel (primary) ASP.NET Core PostgreSQL React GraphQL
React Native replaced Ionic as our mobile framework — better performance, closer to native behaviour, and the same JavaScript ecosystem our front-end team already used. FieldPlanr, SkedPlanr, and the mobile companions to our ERP platforms were rebuilt or freshly built on React Native. ASP.NET evolved to ASP.NET Core — cross-platform, significantly faster, and a major improvement in developer experience. Laravel continued to be our primary PHP framework — it had matured considerably and the ecosystem around it (Forge, Vapor, Horizon, Telescope) made it a genuinely productive platform for building at scale.
Lesson: React Native was worth the migration from Ionic. The native-feel difference is real and users notice it. Some migrations cost more than they save. This one paid for itself.
2024
AI era — now
AI-native development — custom MCU training — Python AI services
Python (AI/ML) Custom MCU training RAG pipelines LLM integration Laravel .NET React Native
The same instinct that led Vikash to build cloud CRM in 2002 — before "SaaS" was a word — is driving the AI layer now. We began deliberate AI adoption in 2024 as a commitment, not an experiment. PrintPlanr built its own MCU server infrastructure for proprietary model training — keeping client data entirely within the platform rather than sending it to third-party AI APIs. Active AI capabilities in production: press recommendation engine, automatic job coding, product suggestions, AI chatbot for customer self-service. ElementIQ AI is in active development — invoice parsing against contract terms, automated job scheduling. Python services layer underneath the existing stacks for AI workloads. Every new application we design now has the AI capability layer designed in from the architecture phase.
Lesson: The pattern repeats. In 2002, building for the web when everyone built for the desktop was the early move. In 2024, building AI-native when most businesses are still evaluating AI is the same instinct. Early adoption of the right technology has compounding advantage.
The current stack — what we build on today
// Infomaze current technology stack — 2025
Backend
Laravel (PHP) — primary ASP.NET Core (.NET) Python (AI/ML services)
Frontend
React Blade (Laravel)
Mobile
React Native (iOS + Android)
Database
MySQL PostgreSQL SQL Server (Microsoft projects) Elasticsearch (search-heavy) Redis (caching/queuing)
Cloud
Microsoft Azure (AWS Partner) AWS
AI layer
Custom MCU training infrastructure RAG pipelines LLM integration Python AI services
Platforms
Zoho (Authorised Partner) Shopify WordPress Magento
APIs
REST GraphQL Webhooks SOAP (legacy) FTP/Email ingestion
What stayed and what we left behind
Still in use — and why
SQL Server — 23 years in. Excellent for complex relational data in Microsoft ecosystems. Never gave us a reason to leave.
Laravel — our primary PHP framework since 2010. The ecosystem matured around it. We matured with it.
Elasticsearch — nothing else handles geo-spatial search at the scale of 42M+ records with the same performance profile.
SOAP — kept alive because some legacy systems still require it. Not preference — necessity.
REST APIs — the default for integration. Not going anywhere.
Retired — and why
Classic ASP — replaced by ASP.NET when the ecosystem matured. Nothing built on it today.
MS Access — replaced by SQL Server as soon as workloads justified it. Access was never meant for application back-ends at scale.
CakePHP — replaced by CodeIgniter, then Laravel. Each was better than the last. No sentiment.
Web Forms — replaced by ASP.NET MVC. The event-driven model didn't scale well to complex application UIs.
Ionic — replaced by React Native. The native-feel tradeoff wasn't worth it for the use cases we build.
jQuery — mostly replaced by React. Still in legacy codebases we maintain but not in new builds.
The principles that didn't change across 23 years
Technology changed every few years. These four things didn't.
01
Build for the client's ecosystem — not for our preference
PrintPlanr is on Laravel rather than .NET because the print industry runs Linux hosting and the talent pool is PHP. ElementIQ is on .NET because the client's infrastructure and integrations are Microsoft. Technology choice should follow the environment, not the engineer's comfort zone.
02
The data model outlasts the framework
We've rebuilt applications on new frameworks without touching the underlying database design. We've migrated databases once in 23 years and it was painful both times. Choose the data layer carefully. Choose the framework knowing it will probably be replaced in 7 years.
03
Early adoption of the right technology compounds
Cloud delivery in 2002 before anyone called it SaaS. REST when SOAP was still the standard. React Native when Ionic was dominant. AI-native in 2024 when most businesses are still evaluating. Being early on a technology that proves correct gives compounding advantage — in knowledge, in product capability, in the problems you've already solved.
04
Pragmatism over purity — every time
We have legacy SOAP integrations running in production alongside modern webhook integrations. We have SQL Server databases alongside MySQL databases. We have Classic ASP in our history and Python AI services in our present. A software company that is still building after 23 years made a lot of pragmatic decisions. The perfect stack always loses to the working one.
The technology we use is not who we are. The problems we solve and the depth with which we understand them — that's who we are. The stack is how we solve them at a given moment in time.
What we'd tell our 2002 selves
Three things.
The data model is the most important decision you'll make on any project. We learned this slowly and expensively. Application frameworks come and go — the data that underlies them accumulates for decades. Model it carefully. Think about how it will need to grow before it needs to grow.
Adopt AI earlier than feels comfortable. We adopted cloud delivery in 2002 and it took years for the market to catch up. If we'd known how much early adoption compounded, we'd have been more aggressive about it every time. The same is true now with AI. The businesses that are building AI-native in 2024 will have a significant advantage over those who add AI as an afterthought in 2026.
The technology choice matters less than the engineering discipline around it. Clean code, proper testing, good documentation, sensible architecture — these produce better software regardless of whether it's written in Classic ASP or Python. We've maintained 20-year-old systems and inherited 2-year-old systems that were unmaintainable. The difference was discipline, not the technology.
Building something that needs to last more than two years?
Free consultation — 23 years of technology decisions behind every recommendation we make. We'll tell you honestly what stack fits your situation and why.