Custom Web Applications in Morocco
A custom web application exists because off-the-shelf software does not match the workflow. I model that workflow first — roles, documents, inventory, money — then implement it as a Laravel API and a React interface.
Typical products: internal operations tools, customer portals, multi-tenant platforms, and the glue between an existing ERP and a new channel. FRIGO SYS and AnyWare are this shape of work: domain-heavy, used every day, not a demo.
I do not sell a catalogue of modules. If a SaaS product already covers 90% of the job, I will tell you to buy it. Custom work is for the remaining 10% that actually runs the company.
The discovery step is where the real entities get found: a lot, a pallet, an invoice line, a job status — the nouns and verbs of how the business actually works, before any of it becomes a database table. Getting this wrong is expensive later, because every screen and every report ends up built on top of whatever the entities turned out to be.
Anybot and an email tracking system are the automation and infrastructure end of the same idea: custom software built because the exact workflow — browser automation with recovery and logs, or pixel-based tracking with sub-100ms response — did not exist as an off-the-shelf product at the price or shape the job needed.
Business problems
- Off-the-shelf software that fights the warehouse, the fleet or the finance process, forcing staff to work around the tool instead of through it.
- Spreadsheets running a real operation until they fail, usually at the exact moment — end of month, a big order — when failure costs the most.
- A previous “custom” build that is really a pile of unmaintained scripts nobody on the current team understands or dares to touch.
- A workflow spread across three different tools with data re-entered by hand between them, so the 'source of truth' is actually whichever tool someone checked last.
- A previous custom build with no tests and no documentation, so every change is a gamble on what else it might break.
- A workflow that works for the happy path in a demo but has no defined behavior for the edge cases — a returned item, a cancelled order — that make up a real fraction of daily operations.
- No plan for what happens when the person who understands the custom system leaves, so institutional knowledge walks out the door with them.
Development process
- Discover the workflow. Model entities that exist on the floor. Ship a thin module — one real screen doing one real job — before building the rest.
- Laravel API, React UI, production on Linux — same as FRIGO SYS and AnyWare, chosen because it is boring in the way infrastructure should be boring.
- Hand over a system the client's own team — or the next developer — can actually read, with a data model named after the business's own vocabulary, not generic framework nouns.
- Replace the hand re-entry between tools with a single source of truth first, even before the UI is polished, since that is where the real time is being lost.
- Write tests for the parts of the system where a silent bug would actually cost money — billing, stock, permissions — even when the rest of the UI is not fully covered.
- Map the edge cases — returns, cancellations, corrections — with the same care as the happy path, since in most real businesses they are not actually rare.
- Document the system's domain model and key decisions as part of delivery, not as an afterthought, so the knowledge does not leave when one person does.
What you get
- Software that matches how the company actually works, instead of the company reshaping its process to match the software.
- One owner for the whole system, so a bug report does not bounce between a SaaS vendor's support queue and an internal team that cannot see the other half of the problem.
- One source of truth instead of the same data typed into three tools and trusted to stay in sync.
- Confidence to change the system, because the parts where a bug would cost money are actually tested.
- Edge cases — returns, cancellations, corrections — handled by the system instead of worked around by hand because nobody modeled them.
- Institutional knowledge that survives a team change, because the domain model and key decisions are documented, not just remembered.
Selected projects
FAQ
How is this different from full stack development?
Full stack is the delivery model (backend, UI, production). Custom web applications is the product type: software shaped around one company’s process rather than a generic website.
Do you estimate before writing code?
Yes. A short discovery pass on the workflow is cheaper than building the wrong entities. I would rather decline a fit than invent a timeline.