Introduction
Two very different searches use the same words. "Full-stack developer" mostly surfaces freelancer marketplaces — arc.dev, Wellfound — people trying to add one person to a team they already run. "Full-stack development services" surfaces studios and agencies: people (or, in my case, one person) who own a project front to back. Google treats these as separate searches because buyers mean separate things by them.
If you're reading this because you need software built, not a contractor added to your headcount, you're in the second category. Before you take my word for anything about how I build, here's what "full-stack" actually covers.
I'm Ashraf Kamal. I run Arranto alone, which means every project below went through my hands at every layer — not a handoff between a frontend contractor, a backend contractor, and whoever happened to own the database that quarter.
What "full-stack" is actually made of
"Full-stack" gets used as one word, but it's really four separate jobs that happen to live in one person, or one small team, when it's done well.
The part users touch
Frontend: the interface, the forms, the thing that has to feel fast on a mid-range Android phone with patchy connectivity, not just a fast laptop on office wifi. This is where most of the website and web application development conversation stops — and it's also where a lot of "full-stack" claims quietly turn out to be front-end-only work.
The part users never see
Backend: the logic deciding what a request is even allowed to do. Authentication, authorization, rate limits — the parts that never show up in a portfolio screenshot but are the actual difference between software that survives contact with real users and software that doesn't.
The part that outlives the interface
Database and infrastructure: schema design, migrations, backups, the decisions that are expensive to reverse later. A good-looking interface on a bad schema is a demo. A good-looking interface on a schema built for how the business actually operates is a product.
The part nobody asks about until it breaks
Deployment and monitoring: what happens when a payment webhook fails, when a background job silently stops running, when a client calls because "the system is down" and you need to know why in minutes, not after a support ticket routes through three people.
A freelancer hired for "full-stack development" is usually covering the first two of these. A full-stack development service covers all four, end to end, on one project, without three people needing to sync up about what the schema means.
Four real projects, one person, every layer
I'd rather show this than describe it in the abstract.
PulseKart is point-of-sale and inventory software for pharmacies — billing, stock levels, and expiry tracking on one screen, built on Next.js and Node over Postgres. I designed the schema for what a "sale" actually touches (inventory, expiry batches, the till), wrote the API routes, and built the interface a pharmacist uses between customers, where a slow screen isn't an inconvenience — it's a line forming.
Veloria Vault was a storefront migration to headless Next.js — the site, the ad creatives, and the product content managed end to end, not just a visual reskin sitting on the old backend.
SanadOS is currently in pilot: a facilities-operations platform on React and Supabase, tracking assets, work orders, and maintenance history as one system of record instead of the spreadsheet-per-building setup it replaces.
FATOORA Lite is the clearest example of why the backend and infrastructure layers matter as much as the interface. It's an e-invoicing engine built around Saudi Arabia's ZATCA Phase 2 clearance workflow — Next.js and Node on the surface, but the real engineering is the XML generation and cryptographic stamping underneath. That's the part a client never sees on screen and would never know to ask for by name, and it's the entire reason an invoice clears or doesn't.
None of these shipped through a handoff. That's not a claim about being better than a team — a team has real advantages a solo studio doesn't, starting with parallel capacity. It's a claim about what "full-stack" gets you when it's structural rather than a job title: nobody has to explain the schema to whoever's building the API, because it's the same person, and nobody has to explain the API contract to whoever's building the interface, for the same reason.
What that looks like in code
One habit that comes directly from owning every layer: validating input at the boundary where a request enters the system, rather than trusting that the frontend already checked it. Here's the shape of it, stripped down from how mutation endpoints get built across these projects:
```typescript const InquirySchema = z.object({ name: z.string().min(1).max(120), email: z.string().email(), message: z.string().min(10).max(2000), });
export async function POST(req: Request) { const body = InquirySchema.safeParse(await req.json()); if (!body.success) return Response.json({ error: "Invalid input" }, { status: 400 }); // proceed with a value TypeScript and the runtime both agree is real } ```
It's a small pattern, but it only happens consistently when the same person who wrote the form also wrote the endpoint. Split those across two contractors on two different schedules and this kind of boundary-checking is exactly what gets skipped under deadline pressure — invisible until the day it isn't.
"Full-stack developer" vs. "full-stack development service" — the honest difference
If what you need is one more engineer inside a team you already run day to day, reporting to your own lead, you want a full-stack *developer* — a staffing marketplace or a direct hire is the right fit, not a studio.
If what you need is a working product, planned, built, and shipped without you coordinating between a frontend person, a backend person, and whoever handles the database — that's a full-stack development *service*, and that's what the four projects above demonstrate rather than just claim.
There's a smaller, related question worth naming: custom software versus a configured off-the-shelf tool. Full-stack development is how the custom side actually gets built — it's the discipline, not a separate line item on top.
How to evaluate a full-stack studio
Three concrete things worth asking before hiring anyone claiming full-stack capability, mine included:
- Ask who owns the database schema after launch — if the answer changes depending on which layer breaks, that's a real gap.
- Ask to see one project where the same person or team handled the interface *and* the part underneath it that never shows on screen (auth, background jobs, integrations) — FATOORA Lite's ZATCA clearance logic is that kind of proof, not the dashboard sitting on top of it.
- Ask what happens at 2am when something silently fails — a real answer names a specific monitoring or alerting mechanism, not "we'll get back to you."
Where this fits at Arranto
Full-stack development isn't a separate line item here — it's the default, because one person is accountable for every layer on every project. That's also the honest explanation for why a build takes the time it takes: nothing happens in parallel across specialists, it happens in sequence, in one head, which is slower in theory and more consistent in practice. If that trade-off fits what you're building, the contact page is the fastest way to describe the project and get a real answer about scope.