How I approach full-stack development

“Full-stack” gets used to mean “knows a lot of frameworks”. In practice, the useful part of being full-stack is simpler: you can follow a feature from the database row to the pixel on a phone screen and understand every decision in between. That makes you responsible for the whole thing — which is exactly why I like it.

This is the loop I use on client work and on my own products. It is not a methodology with a trademark. It is a set of habits that keep projects from going sideways.

1. Think

Before opening an editor, I try to answer three questions in plain language:

• Who uses this, and on what device? In Nepal the honest answer is usually “someone on a mid-range Android phone on mobile data”. That single fact shapes image sizes, JavaScript budgets and how forms behave.
• What does the business need to happen? Not “a website”, but “people should be able to request a quote without calling during working hours”, or “the shop owner should know which items are running low”.
• What must never go wrong? For a store that is a double charge or a lost order. For a brochure site it might just be a broken phone link. Knowing this early tells me where to spend testing time.

2. Design

Design for me starts with the data model, not the colour palette. If the tables are right, most screens become obvious. If they are wrong, every feature afterwards fights them.

I sketch entities and their relationships, then walk through the main flows on paper: a customer placing an order, an admin refunding it, a report summarising the month. Anything awkward in those walkthroughs is a schema problem worth fixing now, while it costs a migration instead of a rewrite.

Then comes the interface — usually mobile first, because a layout that works at 360px wide almost always scales up gracefully, and the reverse is rarely true.

3. Build

I build in thin vertical slices: one small feature, all the way through — migration, model, validation, controller or action, view, and the tests that matter. A slice that works end to end is worth more than three half-finished layers.

A few defaults I rarely change in Laravel projects:

// Validate at the edge, with a dedicated request class.
public function store(StoreOrderRequest $request, PlaceOrder $placeOrder)
{
    $order = $placeOrder->handle($request->user(), $request->validated());

    return redirect()->route('orders.show', $order);
}

• Form requests for validation and authorisation, so controllers stay short.
• Action classes (PlaceOrder, IssueRefund) for business operations, so the same logic can be called from a controller, a queued job or an Artisan command.
• Database transactions around anything that writes to more than one table.
• Policies for every model a user can touch. “Only the owner can see this order” belongs in one place, not scattered across views.

4. Test

I don’t chase 100% coverage. I test the paths where a bug costs real money or trust: checkout, payments, stock changes, permissions. A feature test that proves “a customer cannot view another customer’s order” has saved me more than any number of trivial unit tests.

I also test like a user: on a real phone, on a throttled connection, with the keyboard only, with a slow API response. Many “bugs” are really design problems that only show up in those conditions.

5. Deploy

Deployment is part of development, not an afterthought. Before the first release I want:

• environment variables documented in .env.example and never committed,
• a repeatable deploy script (install, migrate, cache config and routes, restart queue workers),
• database backups that have actually been restored at least once,
• error logging I will notice.

I have written separately about common Laravel deployment problems — most of them come from skipping one of these.

6. Improve

Launching is the moment real information starts arriving. Which pages people actually visit, where they drop off, which queries get slow when the tables grow. I keep a short list of improvements and work through it in small releases — then the loop starts again with Think.

Why the loop matters

None of these steps are clever on their own. The value is in not skipping any of them. Most projects that go badly don’t fail because of a hard technical problem; they fail because nobody asked who the users were, or the data model was rushed, or the first deployment was improvised on a Friday evening.

If you’re planning something and want a developer who works this way, get in touch.