Software development glossary

Plain-language definitions of the terms we actually use — engagement models, architecture patterns, and technical concepts — explained the way they apply to real projects, not a generic dictionary entry.

Engagement Models

MVP (Minimum Viable Product)

The smallest working version of a product that delivers real value to users, built to test an idea in the market before investing in a full feature set. We typically scope MVPs to a single core user flow and one primary role, which is why MVP-tier web and mobile projects sit at the lower end of our pricing.

Related: Web App Development

Dedicated Development Team

An engagement model where engineers, designers, or QA work exclusively on your product long-term, integrated into your existing tools and sprint cadence, priced monthly per role rather than as a fixed project quote.

Related: Dedicated Development Team

Staff Augmentation

Adding external engineers or specialists to an existing internal team to fill a specific skills or capacity gap, without the overhead of local hiring. Functionally similar to a dedicated team engagement, just typically smaller in scope — one or two roles rather than a full team.

Related: Dedicated Development Team

Fixed-Price vs. Time & Material

Two ways software projects get priced: fixed-price sets one total cost for a defined scope, while time & material bills for actual hours worked as scope evolves. We use fixed-price for well-defined projects and time & material (or a dedicated team) for ongoing, evolving work.

Web & App Architecture

SaaS (Software as a Service)

Software delivered over the internet on a subscription basis rather than installed locally, typically with a shared codebase serving many customers. Most of our web app development work for startups is SaaS product development.

Related: Web App Development

Multi-Tenant Architecture

A system design where a single application instance serves multiple customer organizations ('tenants'), with each tenant's data kept isolated despite sharing infrastructure. This is the core architectural pattern behind most B2B SaaS platforms and requires careful planning around data isolation and role-based access.

Related: Web App Development

API (Application Programming Interface)

A defined way for two software systems to communicate — for example, a mobile app calling a backend to fetch user data. Nearly every product we build, from a marketing WordPress site to a multi-tenant SaaS platform, has at least one API connecting its frontend to its data.

Headless Architecture

Separating a system's content or commerce backend from its frontend presentation layer, so the frontend can be built independently instead of using the backend's built-in templating. We use this pattern for headless Shopify (Hydrogen) and headless WordPress builds when a project needs more frontend flexibility than a traditional theme allows.

Related: Shopify Development

Server-Side Rendering (SSR)

Generating a page's HTML on the server for each request, rather than in the browser after the page loads — improves initial load speed and search engine crawlability. Next.js, our default frontend framework, supports SSR alongside static generation, and we choose between them per page based on how often the content changes.

Related: Next.js

Progressive Web App (PWA)

A web application built to behave like a native mobile app — installable, works offline, sends push notifications — without going through an app store. A lower-cost alternative to native mobile development when app-store presence isn't a hard requirement.

Related: Web App Development

Mobile Development

Cross-Platform Development

Building one codebase that runs on both iOS and Android, using a framework like Flutter or React Native, instead of writing two separate native apps. This is our default approach for most mobile projects because it cuts cost and keeps feature parity easier to maintain.

Related: Mobile App Development

Native App Development

Building an app using each platform's own language and tools (Swift/Kotlin) rather than a shared cross-platform framework. We reach for this only when a project genuinely needs deep platform-specific APIs or performance beyond what cross-platform delivers.

Related: Mobile App Development

AI & Automation

RAG (Retrieval-Augmented Generation)

An AI architecture pattern where a language model's response is grounded in retrieved content from your own data (documents, database records) rather than relying only on what the model was trained on. This is how we build AI search, support copilots, and Q&A features that answer accurately from your actual content.

Related: AI Development

LLM (Large Language Model)

The underlying AI model that powers features such as chatbots, summarization, and content generation. Most of our AI development work integrates and orchestrates existing LLMs around your data and workflows rather than training a new model from scratch.

Related: AI Development

AI Guardrails

Rules, checks, and fallback logic built around an AI feature to constrain its outputs and catch failures — for example, preventing a support copilot from making promises it shouldn't, or falling back to a human when confidence is low. We treat guardrails as a core deliverable on every AI feature, not an afterthought.

Related: AI Development

Prompt Engineering

Designing the instructions and structure given to a language model to get reliable, accurate outputs for a specific use case. A meaningful part of AI feature quality, but only one piece — retrieval design and evaluation criteria matter at least as much for production reliability.

Related: AI Development

E-Commerce

Headless Commerce

Running your storefront's frontend independently from your commerce backend (like Shopify), giving full control over the shopping experience while still using Shopify for inventory, checkout, and order management. Worth the added complexity only when a theme genuinely can't deliver the frontend experience you need.

Related: Shopify Development

Shopify Plus

Shopify's enterprise tier, offering features like Shopify Scripts and Flows, higher API limits, and multi-currency/market support at scale. Most stores don't need it — we'll tell you honestly if standard Shopify covers your needs before recommending an upgrade.

Related: Shopify Development

Content & CMS

CMS (Content Management System)

Software that lets non-technical teams create and update website content without touching code — WordPress is the most common example. We build structured, deliberate content models rather than relying on default settings so editing stays easy as a site grows.

Related: WordPress Development

WooCommerce

An e-commerce plugin that turns a WordPress site into an online store — product catalogs, checkout, and order management built on top of WordPress's content system. We use it when a client wants an online store integrated into an existing WordPress content site rather than a dedicated Shopify build.

Related: WordPress Development

Delivery & Quality

Core Web Vitals

Google's set of measurable page-speed and stability metrics (loading, interactivity, visual stability) that factor into both user experience and search rankings. We build with performance budgets from the start rather than treating speed as a post-launch cleanup task.

Technical Debt

Shortcuts taken during development that make a codebase harder to change later — usually the real cause of a site or app that's become slow, fragile, or expensive to update. Most of our WordPress and legacy-rebuild work involves paying down technical debt accumulated from plugin sprawl or rushed original builds.

Related: WordPress Development

Sprint

A fixed, short work cycle (typically one to two weeks) in which a defined set of features gets built and demoed. All of our development work — service projects and dedicated teams alike — runs on a sprint cadence so you see real progress throughout the build, not just at the end.

CI/CD (Continuous Integration / Continuous Deployment)

Automated pipelines that test and deploy code changes as they're made, rather than manually pushing updates in large, risky batches. Standard practice on every project we build, reducing the chance a deploy breaks something in production.

Have a specific project in mind?

Tell us what you are building and we will recommend the right approach, technology, and engagement model.

Talk to Codexa Soft