Glossary

App development, in plain English.

Terms that keep coming up in conversations about apps and software, in one to three sentences. For anyone who wants to build on an existing app or bring a senior engineer into their team without being a developer themselves.

Languages and frameworks

Flutter: Google's framework for building iOS and Android apps and web UIs from one codebase. One team ships both platforms from the same code, and both stay in step.
Dart: The programming language behind Flutter. Built by Google, easy to read, and made for apps that run smoothly on phones.
Swift: Apple's language for iPhone, iPad, and Apple Watch apps. It comes in when an app is built natively or when a Flutter app needs something only iOS offers.
SwiftUI: Apple's toolkit for building interfaces in Swift. You describe what a screen should look like instead of assembling it step by step, which makes changes easier.
Kotlin: The language for native Android apps, also used on the server. It shows up for Android-specific features and for backend services.
TypeScript: JavaScript with types. Bugs show up while you write the code, not when a user runs into them. That's why it's the standard for larger web UIs and for Node.js services.
Node.js: JavaScript on the server. A good fit for lean services and APIs that feed an app with data.
Firebase: Google's bundle of services for apps: database, sign-in, file storage, push notifications. It saves you from running your own servers, but it ties you to Google.
Supabase: An open-source alternative to Firebase, built on PostgreSQL. You can host it yourself, for example on servers in the EU.
Appwrite: Another open-source platform for app backends, with sign-in, database, and file storage, that you can run on your own infrastructure.

Architecture and code

Architecture: How the software is divided into parts. It decides whether the next feature is easy or expensive.
Module: A self-contained part of the app with one clear job, such as sign-in or order management. A good module can change without breaking something elsewhere.
Monorepo: Several apps in one shared repository, so shared code exists only once. Worth it as soon as one app turns into several.
Melos: A tool for managing a monorepo with several Flutter and Dart packages. It runs commands and tests across all of them and manages their versions.
State management: How an app keeps track of its data and of what's on screen, so that screens stay testable.
BLoC: A common pattern for state management in Flutter. It keeps the logic strictly apart from the interface: events go in, states come out.
Riverpod: Another option for state management in Flutter. It provides data and dependencies where they're needed and is easy to test.
Technical debt: Shortcuts in the code that you pay back later, with interest. Every change gets a little more expensive until someone pays the debt down.

Delivery and quality

CI/CD and pipelines: An automated run that builds the app, tests it, and uploads it to the stores. Anyone on the team can start it.
DevOps: Everything it takes to move an app from code to the stores. That covers the pipeline, code signing, store uploads, and the tools behind them. For apps, the point is that every version ships the same way.
Codemagic: A CI/CD service made for Flutter apps. It builds iOS and Android versions in the cloud and uploads them to the stores. Nobody on the team has to keep a Mac around for iOS builds.
Code review: A second pair of eyes before code is merged. Bugs show up early, and knowledge spreads across the team.
Pull request: A proposal to merge a change into the main branch, review included. GitLab calls it a merge request.
Merge: Bringing a change into the main branch, usually after its pull request passes review. After the merge, the change is part of the code the team builds the next release from.
Diff: A comparison of old and new code that shows which lines were added, removed, or changed. In a code review, the diff is mostly what the team reads.
Unit test: An automated test for a small piece of logic, such as a calculation. It runs in seconds and fails the moment a change breaks something.
Widget test: An automated test for one part of a Flutter interface. It checks that a screen shows the right thing and reacts correctly to input.
Integration test: An automated test that runs the app on a device or emulator, say from sign-in to a submitted form. It checks that all the parts work together.
Release: A version of the app that reaches its users, usually through the App Store or Google Play.
TestFlight: Apple's service for handing a new version of an app to testers before it appears in the App Store. Google's counterpart is internal testing in the Google Play Console.
Google Play Console: Google's dashboard for apps in the Play Store. In the console, the team submits new versions and releases them to internal and closed testing tracks. The team also keeps the store listing up to date and checks the reports there.
Code signing: The digital proof that an app really comes from its publisher and hasn't been tampered with. Without valid certificates and keys, no store accepts an update.

Mobile and devices

Offline-first: The app works without a connection and syncs as soon as it's back. Entries land on the device first, so nothing gets lost.
Field data capture: Recording data in the field with photos, location, NFC, and timestamps, even without a connection.
NFC: Near Field Communication: short-range radio that works within a few centimeters. A phone reads a chip on a machine, a door, or a badge. From each scan, an app can tell what someone is working on, and where.
Cross-platform: One codebase for several platforms, such as iOS and Android, instead of two separate apps. With Flutter, a web version comes from the same code too.
Native development: Building an app directly in the platform's own language: Swift for iOS, Kotlin for Android. The right call when an app is tightly bound to the device. Flutter apps have native parts too, for special hardware for instance.
Flutter Web: Flutter in the browser. The app's codebase can also produce a web interface, such as a back-office tool. The app and the web interface share the same data models and business rules.

Integration

API: An interface two programs use to talk to each other, such as the app and the server. It defines which data you can request and send, and how.
REST: The most common way to build an API. Data is requested and changed through plain web addresses, much like opening a web page.
Backend: The part of a system that runs in the background on a server: storing data, enforcing rules, connecting services. The app is the surface, the backend is the machine behind it.
Authentication: Checking who is signing in, whether by password, code, or a link sent by email. For apps there are ready-made services like Firebase Auth, Supabase, or Appwrite that handle this securely.

Collaboration and AI

Joining your team: An experienced developer, embedded in your existing team for a while: your sprint, your repository, your process. Unlike an agency, they don't take over the project. They build with you.
Two halves of one system: A web interface for the back office and an app for the field, equal partners drawing on the same data.
Sprint: A fixed stretch of work, usually two weeks. The team commits to a goal and shows a result at the end. Then it plans what comes next.
Coding agent: A tool like Claude Code or Codex that works on its own inside a repository. It reads the code, plans a change, writes it with tests and documentation, and runs the checks. A harness spells out what the agent may change and the conditions for a merge.
Harness: Written rules and checks that apply to everyone who writes code, human or model. They include coding conventions, tests that run before every merge, and limits on what an agent may change. The rules and checks live as files in the repository.
Claude Code: Anthropic's coding agent, working in the terminal and in the editor: it reads code, proposes changes, and carries out tasks. Like any model, it needs a firm frame and reviewed results.
Codex: OpenAI's coding agent. It takes on tasks in the repository, such as implementing changes or writing tests. Here too, a person reviews the results before they're merged.
CodeRabbit: An AI service that reviews pull requests automatically and leaves comments. It doesn't replace review by people, but it catches a lot early.
Board: A shared view of a team's tickets, in a tool like Linear or Jira. It shows what's up next, what's in progress, and what's done.
Ticket: A single task with a description, an owner, and a status, tracked in a tool like Linear or Jira. Anyone can check a ticket to see where the work stands.

Tools and communication

Linear: A tool for tasks and project planning: tickets, sprints, and roadmaps in one place, fast and uncluttered.
Git: The tool for version control. Every change is traceable, several developers work in parallel, and any earlier state can be restored.
GitHub: A platform for Git projects with pull requests, reviews, and automation (GitHub Actions). Many teams keep their code here.
GitLab: An alternative to GitHub that you can also host yourself. Changes run as merge requests, and pipelines are built in.
Slack: Team chat with channels by topic. Quick conversations instead of long email threads.
Discord: Originally built for gaming communities, now used by many developer teams as a chat with voice channels.
Microsoft Teams: Chat, video calls, and files from Microsoft in one app, common in companies on Microsoft 365.
Repository: The place where a project's entire source code lives together with its history, usually on GitHub or GitLab. Anyone with access sees every version and every change.

Call

Let's talk about what you want to build next.

On a thirty-minute video call, you tell me what's coming up and how your team works today. I'll tell you if I can help, and how. By the end, you'll know whether it's a fit.

Book a call Send a message