Tools & Stack Guide
A plain guide to common development tools
Agency proposals arrive full of tool names. This guide explains what the common ones are for, so you can follow a technical conversation about web development without having to learn to code.
Frontend
What users see and touch
The frontend is the part of a product that runs in the browser or on the phone. It covers layout, buttons, forms, and everything a user interacts with. Two names dominate this space: React and Vue.js. Both are used to build interfaces, and both are mature enough that the choice usually comes down to team experience rather than technical limits.
When a proposal lists a frontend tool, the useful question is not which name sounds newer. It is whether the team building your product has shipped with it before, and whether the interface they describe — the screens, states, and edge cases — matches what your customers actually do.
Interface layer
Everything a customer taps, reads, or types lives here. It is the layer most affected by UI/UX decisions and the one your team will review most often in demos.
Common names
- React — component-based interfaces, dashboards, portals
- Vue.js — interactive interfaces, progressive web apps
Frontend — the layer your customers touch
React and Vue.js
React is built around components, which are reusable pieces of interface, and it is common in dashboards, portals, and single-page applications. Vue.js is known for a gentler learning curve. It suits interactive interfaces and progressive web apps, and its ecosystem includes Nuxt for server-rendered sites.
For a business owner, the practical difference is small. What matters is whether the agency can explain why one suits your product, and whether they can maintain it after launch. A team that has shipped both will usually say so plainly.
Server rendering
Next.js and pages search engines can find
Next.js was created by Vercel and first released in 2016. It adds routing, server rendering, and production features on top of React. That matters for SEO-friendly websites and content platforms, where pages need to be found by search engines. It is also used for app-like experiences that still need to load fast.
When a project needs both interactivity and search visibility, Next.js is often the fit. A marketing site with a logged-in area, or a catalogue that must rank in search, is the typical case.
Sketching the flow before development starts keeps the conversation about screens concrete.
Backend
Where the logic lives
The backend handles data, accounts, payments, and business rules. It is the part a customer never sees but always feels — slow lookups, lost records, and broken logins all live here.
Laravel as a common backend choice
Laravel is an open-source PHP framework first released in 2011, built around an MVC structure with routing, authentication, and database tooling. MVC simply means the code is separated into the data model, the screens, and the logic that connects them, which makes larger projects easier to navigate.
Agencies often use it for custom web apps and admin systems because it speeds up structured backend development. It is not the only option, but it is a well-trodden one, and API integration with payment providers or mapping services is routine.
Databases
PostgreSQL and where your data sits
PostgreSQL is an open-source relational database with roots in the POSTGRES project from the 1980s. It is known for reliability, extensibility, and strong SQL support. It appears in web applications, analytics, and transactional systems, and it is frequently the main database behind custom apps.
Relational structure
Data is stored in linked tables, which suits orders, accounts, and anything with clear relationships between records.
Extensible
Extra data types and functions can be added as a product grows, so the database does not need replacing early.
Strong SQL support
Reports and analytics can be written in standard SQL, which most developers already know.
For most business applications, it is a safe default that will not need replacing as the product grows. If an agency proposes something else, it is fair to ask what that choice buys you.
Data layer — reliability and reporting
Design
Figma before the first line of code
Figma launched in 2016 and is used for interface design, prototyping, and design systems. It runs in the browser and supports real-time collaboration, which means designers and clients can look at the same file at the same time.
It is common in web and app projects before development begins. The handoff from Figma to developers affects how closely the finished product matches the design, so it is worth asking how that handoff works — file comments, a shared review, or a written spec.
Real-time collaboration also changes meetings. Instead of describing a change, a designer can make it while you watch, which shortens feedback loops and reduces the chance of a misunderstanding surviving into build.
Planning
Miro and the discovery phase
Miro began in 2011 as RealtimeBoard and is used for workshops, user flows, wireframes, and planning. It is common in the discovery phase, before design and development start. Teams use it to map customer journeys and app structure on a shared board.
A discovery board is where the project's assumptions get written down. If a proposal skips this stage, the questions it would have answered usually resurface later as change requests.
What a shared board gives you
- A customer journey everyone can point at, not a verbal description
- A first pass at the app structure before visual design begins
- Decisions recorded where the whole team can see them
The value is less about the tool and more about getting decisions out of people's heads and onto something everyone can see.
Location services
Google Maps Platform for addresses and routes
Google Maps Platform provides mapping, geocoding, routing, and places data. It is widely used in delivery, transport, travel, and location-based apps, and it supports both web and mobile integrations. Geocoding means turning a written address into coordinates a map can plot.
For logistics and local-service products, it is often the backbone of the app's core feature. If your product depends on addresses, routes, or nearby places, this is the layer that handles it — and it is usually billed by usage, so volume matters.
What this layer covers
- Mapping — showing where something is on a map your customers can pan and zoom.
- Geocoding — converting an address into a point, and back again.
- Routing — working out a path between two points and how long it takes.
- Places — looking up businesses, landmarks, and points of interest near a location.
How it fits together
How the pieces fit together
A typical project might use Figma for design, Miro for planning, React or Vue.js on the frontend, Next.js where search visibility matters, Laravel on the backend, PostgreSQL for data, and Google Maps Platform for location features. Not every project uses all of these. The point is that each name has a job, and knowing the job makes proposals easier to read.
Planning and design
Miro and Figma come first. Decisions and screens are settled before any code is written, which is where most project risk is reduced.
Interface
React or Vue.js builds what customers see. Next.js is added when search engines need to index the pages as well as serve them.
Logic and data
Laravel handles accounts, payments, and business rules. PostgreSQL stores the records those rules act on, and keeps them queryable for reporting.
Location
Google Maps Platform sits alongside the app when addresses, routes, or nearby places are part of what the product does.
Four layers — each name has a job
What you do not need to decide
You do not need to pick a stack. That is a technical decision, and it should follow from the product's requirements. What you can do is ask why a team chose a particular tool, and whether they can support it after launch. That question matters more than the tool itself.
If the answer is a list of names with no reasoning, that is worth noticing. A good answer names the problem the tool solves for your product, and says what happens if it turns out to be the wrong fit.
Questions readers ask most
How do I know if an agency can handle both design and development?
Ask who does the design, who builds it, and how they hand off between the two. Teams that do both should be able to explain their process clearly. If design and development are separate, ask how feedback moves between them.
What should be included in a discovery phase before development starts?
Discovery should map the problem, the users, and the core features. It should produce wireframes or a flow, a defined MVP scope, and a rough timeline. If a proposal skips this stage, ask why.
Do I need to understand the tools to approve a project?
No. You need to understand what each tool is for, roughly, and why the team chose it. That is enough to ask useful questions and spot vague answers.
Where to go next
This guide covers what the common tools are for. Two related guides go further: one explains how development approaches differ, and the other walks through what to prepare before a project starts.
ViewBinary Digital
If a tool name in a proposal is unclear, ask us what it is doing in your project. We write these guides for business readers in Singapore and publish them openly.
- Email[email protected]
- Phone+65 6208 6962
- HoursMonday to Friday, 9:00 AM – 6:00 PM
- OfficeParkveien 15, 0350 Oslo, Norway
ViewBinary Digital — Parkveien 15, 0350 Oslo, Norway