Optical shop management SaaS
Asaan Optics
Optical shop software for Android and Windows: prescriptions, counter sales, stock and staff shifts on one shared shop account.
- SaaS product
- Mobile app
- Desktop app
- Business system
System design and software architecture for products that have to last
Most problems in business software come from decisions made before the first screen: how data is modeled, where rules are enforced, how clients sync and who is allowed to do what. I help teams make those decisions deliberately, either as part of building the product or as a separate design and review piece of work.
More than once I have designed one backend shared by several client apps. Asaan Optics runs Android and Windows apps on one multi-tenant API, and KAYANAK runs a public website, an admin CRM, partner portals and a Flutter app on one NestJS API. I have also audited existing codebases, including a multi-tenant education platform and an expat utility app that I then rebuilt module by module.
What the service includes
Architecture and data model design
Modules, entities, relationships and boundaries, written down before the build so everyone builds the same system.
Multi-tenant and role design
Tenant isolation, organizations and branches, roles and permission matrices.
API contracts
Versioned REST contracts with OpenAPI documentation, shared by the web, mobile and desktop clients.
Offline sync and consistency
Idempotency keys, durable queues, dead-letter handling and server-issued serial numbers for apps that write while offline.
Security review and hardening
Authentication, sessions, privilege checks and secrets handling reviewed and fixed, with findings ranked by risk.
Codebase audits
A written assessment of an existing product: what works, what is missing, what is risky, and the order to fix it in.
Integration design
Payments, messaging, AI services and e-invoicing placed behind clear interfaces, so a provider can change without a rewrite.
Problems it solves
- A system that breaks as it grows
- Features added onto a weak data model cause bugs in places nobody touched. A clear model and module boundaries keep each change local.
- Numbers that do not add up
- One sale should reduce stock, update the customer's balance, create the invoice and appear in reports. If those writes are not in one transaction, the figures drift apart.
- Duplicates from retries and offline work
- Retries over a bad connection can record the same sale twice. Idempotency keys carried from the client queue to the server prevent it.
- Inherited code nobody trusts
- When a team takes over a product, it needs to know what is safe to ship. An audit turns that uncertainty into a prioritized plan.
- Every client with its own copy of the rules
- When the website, the app and the admin panel each calculate prices or permissions separately, they disagree. Rules belong in one backend that every client calls.
How I approach it
I start from the business action, not the table. A sale, a booking or a lease touches several records, so I map what must change together and wrap it in a transaction. It is the point I make when I write about ERP software: creating records is easy, and keeping every connected record consistent is the real work.
KAYANAK runs on a NestJS modular monolith with Prisma and PostgreSQL, which I built as lead developer: one deployable service with clear modules, shared core services and in-process events, so commissions, the CRM and notifications react to the same business events without being tied to each other. For Just Book, a home-services marketplace still in development, the Laravel backend owns pricing, a booking state machine and availability slots that prevent double-booking, so the app never decides those on its own.
When I review an existing system, I write it up first. On Arab Expat I began with an audit of 61 findings, then rebuilt the product module by module against written architecture contracts. On CampusPro, a multi-tenant .NET and React platform built by another developer, I wrote an audit and then a security patch, with the project's first integration tests, to close privilege-escalation paths. I describe findings plainly and fix the riskiest ones first.
Technologies I use for this
- Node.js
- NestJS
- TypeScript
- Laravel
- PHP
- PostgreSQL
- MySQL
- Prisma
- Flutter
- Firebase
Typical stages
- Stage 1
Understand the domain
The business actions, the people involved, the data they depend on and the constraints, such as offline use or tax rules.
- Stage 2
Model and boundaries
Entities, relationships, modules and the transactions that must succeed or fail together.
- Stage 3
Design document
Architecture, API contract, security model and hosting, written down and reviewed with your team.
- Stage 4
Prove the risky parts
Sync, payments or integrations that could sink the project are built and tested first.
- Stage 5
Build or hand over
I build the system, or support your developers while they build against the design.
Related work
Car marketplace and sales CRM
KAYANAK
Arabic-first car marketplace and sales CRM for a Riyadh car business, with installment pricing, car-wash booking and an AI sales assistant.
- Web application
- Mobile app
- E-commerce
- Business system
Personal utility app for expats
Arab Expat
An offline-first Android app that helps expats in Saudi Arabia track documents, overtime, spending, remittances and their labor rights.
- Mobile app
- Business system
Frequently asked questions
Who is Farhad Nazir?
Farhad Nazir is a full-stack software developer based in Riyadh, Saudi Arabia. He builds web applications, SaaS platforms, Flutter mobile apps and Windows desktop software, and is the founder and developer of Asaan Optics, published by his company Techwine Solutions. He holds a bachelor's degree in software engineering from COMSATS University Islamabad and has worked at GOFTECH, Exytex Technologies and Cognitojs.
Can you review an existing codebase?
Yes. I produce a written audit covering architecture, security, the data model, missing features and deployment, with findings ranked by risk and a plan to fix them. I did this for Arab Expat and CampusPro before changing any code.
Do you only design systems, or also build them?
Both. Most of my architecture work is on products I then build, such as Asaan Optics and KAYANAK. I can also produce a design for your own team to implement and review their work against it.
Should my product be a monolith or microservices?
For most business products I start with a modular monolith: one deployable service with clear internal modules. It is simpler to run and change, and modules can be split out later if load or team size calls for it. KAYANAK runs this way on a single NestJS API.
How do you handle offline apps and sync?
Every write from the client carries an idempotency key, writes that cannot be sent wait in a durable queue, and the server replays its first answer instead of recording a repeat. Failed items go to a dead-letter list instead of disappearing, and numbers such as invoice serials are issued by the server so phones and PCs never collide.
Do you work remotely with international clients?
Yes. I am based in Riyadh and have delivered work for businesses in Saudi Arabia and Pakistan, and Asaan Optics is set up for shops in Pakistan, Saudi Arabia and India. I work through calls, shared documents and regular builds you can test.
Have a software idea or a business process that needs a proper system?
Tell me what you are trying to fix. I will reply with honest questions, a practical plan and a realistic estimate.