What gets built
Web applications, mostly, because that is where a business problem and a browser meet. The common thread is that each one replaces something that used to be done by hand, in a spreadsheet, or in a tool that almost fit.
- SaaS products: multi-tenant from day one, with billing, trials, roles and the admin side nobody budgets for
- MVPs: the smallest version that can take money from a real customer, built to be extended rather than thrown away
- Internal tools and back offices: dashboards, approval flows, dispatch, reporting - the software your team actually uses all day
- Customer portals and self-service: accounts, documents, orders and requests, connected to whatever system holds the truth
- Process automation and AI tooling: document and data pipelines, integrations between systems, and AI where it removes real work rather than adding a chat box
- E-commerce around the edges: headless storefronts, custom integrations and the apps a PrestaShop or Shopify store needs but cannot buy
Custom software development by one person who also has to sell it
A software company sells you a project manager, a designer, a developer and a QA engineer, and then hands you a product with no customers. The two products I own - svezapausal.rs for Serbian flat-rate taxpayers and AdvokatX for law firms - were architected, built, priced, marketed and supported by me. Both earn their users through free tools and guides that answer the exact questions people type into Google, which is marketing a developer does not usually think about and a marketer cannot usually build.
That is the difference I sell. The architecture is designed around how the product will be found and paid for, not just how it will run. The SEO is in the first commit. The onboarding is written by the person who built the signup. And when something breaks at nine in the evening, the person who answers is the one who wrote it.
How a project runs, from idea to a first paying customer
It starts with the problem, not the feature list: who has it, what it costs them today, what they would pay to be rid of it. From that comes a short architecture document - data model, system boundaries, what is built and what is bought - and an MVP scope small enough to ship in weeks rather than quarters.
The build happens in increments on a staging environment you can open, with every change in version control and deployed through a pipeline, so there is never a big reveal. Launch is a checklist, not an event: domains, analytics, Search Console, error monitoring, backups, a support address. Then we measure what users do and iterate on that, not on opinions.
The code is yours, in your repository, documented. Nothing is locked into me, and the people I bring in for a bigger scope are ones I have already delivered with. Scope and cost depend on the problem in front of me, so there is no rate card; tell me the problem and I will tell you what it takes.
Process automation and AI, where they pay off
Most automation requests are really a request to stop doing one repetitive thing: re-keying orders, chasing documents, copying data from one system to another, reading logs by hand. Those are solved with integrations and small services, not platforms. I build my own tooling the same way - a Search Console archive that outlives Google’s retention, a content-analysis CLI, log readers - and the same approach works inside a client’s business.
AI goes in where it removes real work: classifying and extracting from documents, drafting from structured data, answering from a known corpus, routing requests. It stays out where a rule would do, because a rule is cheaper, faster and does not hallucinate. The architecture decides that per task, and I will say which is which.
The stack, and why
Next.js and React when the product is public-facing and search matters, because server rendering and Core Web Vitals come built in. Vue and Nuxt when a team already lives there. Laravel when the product is a business application with roles, billing and reporting - AdvokatX runs on Laravel, Inertia and Vue. Node and Express for services, integrations and real-time work. PostgreSQL or MySQL underneath, AWS or Vercel on top, and a CI pipeline from the first week.
Ten years in these, on products that are still running. If you are looking for a Next.js developer, a Laravel developer or a Node developer, the honest answer is that you are looking for someone who can choose between them for your problem, and that is the part I am hired for.
