Custom Web Application Development

Most of the web software we write is for ourselves. FanDesk, Mobile Master, SteelFlow MES, EnergyFile and FanMail's admin side all started as internal projects before they became products, and the same people and the same codebase habits go into client work. So when you hire Fanpino for a custom web application, you get the stack we already run in production every day, not one assembled for your project.

Who this is for

Companies whose process doesn't fit an off-the-shelf tool, or fits it only after a lot of spreadsheets on the side. Typical cases: an internal portal that has to talk to an existing ERP, a workflow with approvals and an audit trail, a customer-facing dashboard, or a product you want to sell as SaaS later. It also suits teams that need the software to run on their own servers, sometimes on a network with no internet access at all.

It's probably not for you if a WordPress plugin or a standard CRM already does 90% of the job. We'll say so in the first call.

How a project runs

1. Scoping call and brief. We talk through the users, the data and the one or two workflows that matter most, then send back a short written brief with what's in and what's out.
2. Data model first. Before any polish, we model the data and build one screen end to end, from database to browser, so you can click through something real in the first weeks.
3. Short cycles on staging. Work lands on a staging URL you can use. You see progress as working software, and changes get discussed against the actual screen.
4. Tests and review. Business rules get unit tests; the API gets integration tests against a real database. On SteelFlow MES that meant typed Python (mypy in strict mode) and CI that blocks a merge when anything fails.
5. Go-live and handover. We deploy with Docker, set up backups and monitoring, and hand over the code, the environment files and a short runbook.

The stack we actually use

Backends are Python with FastAPI and Pydantic. For data we pick MongoDB when documents are the natural shape (FanDesk, Mobile Master, EnergyFile) and PostgreSQL when relations and transactions are the point (SteelFlow MES keeps its whole weld-to-part traceability chain in Postgres). Redis handles caching and background job queues through arq. Frontends are React with TypeScript, built with Vite, or Next.js where server rendering helps; this site itself is Astro. Everything ships as Docker images behind Traefik.

A few habits carry across projects: permissions are checked on the server, never only in the UI; every write that matters is logged; and the interface works in Persian, English and Arabic with correct right-to-left layout, not a mirrored afterthought.

Work you can look at

SteelFlow MES is a manufacturing execution system for steel fabrication. It imports a Tekla model into a bill of materials, tracks every part through the shop floor, and links heat numbers, welder qualifications and NDT results to each piece. FanDesk is a helpdesk with SLA rules that follow real business hours and holidays; its engine also runs the IT service desk of a public university, next to four other systems under one sign-on.

Further reading

• How SteelFlow turns a Tekla model into a BOM without manual re-entry
• Fixing a stored XSS through PDF attachments in FanDesk

Frequently asked questions

How much does a custom web application cost?

It depends on scope, so we don't publish a price list. After the scoping call you get a written estimate tied to the brief, and changes to the brief get re-estimated before work starts on them.

Do we own the source code?

Yes. For custom projects the code, database and deployment files are handed over to you. If part of the project reuses one of our products, we agree the licence for that part in writing up front.

Can it run on our own servers?

Yes. Everything we build ships as Docker containers, so it runs on your hardware or a cloud VM. We already deploy to a server with no internet access by copying images over SSH instead of pulling from a registry.

Can you connect it to our existing systems?

Usually. We've built integrations with national single sign-on, SMS gateways, payment gateways and a Tekla plugin. If your system has an API or even a database we can read, we can work with it.

MongoDB or PostgreSQL?

Whichever fits the data. Documents with flexible fields go to MongoDB; anything with strict relations, money or traceability goes to PostgreSQL. We'll explain the choice in the brief.

What happens after launch?

We stay on for bug fixes and small changes under a support agreement, with monitoring and nightly backups set up from day one. If you'd rather run it yourselves, the runbook covers deploys and restores.