Software Engineering
Software Architecture That Can Grow with the Product
Software architecture design and system architecture practices a client can point at. A Kolkata studio at dhinova.com draws the map first.
Dhinova Team ·
Architecture is the set of decisions that are expensive to reverse. Good architecture protects delivery speed six months from now without blocking shipping this month.
Fundamentals that stay true
Separate domains that change for different reasons. Keep business rules out of UI components. Make data ownership obvious. Prefer boring technology for core paths and experiment at the edges.
Principles we apply on client projects
- Start modular monolith unless team and scale clearly demand microservices.
- Design APIs around use cases, not database tables.
- Encode invariants close to the data write.
- Observe production early: logs, metrics, traces, and error budgets.
Patterns worth knowing
MVC and layered services still help small teams. Event-driven flows help when multiple systems must react to the same fact. Microservices help when independent deployability is worth the operational cost - not as a status symbol.
Decision records beat folklore
Write short ADRs for major choices: auth model, multi-tenancy, queue vs sync calls, and storage. Future you will forget why the path of least resistance looked correct on a Tuesday.
Conclusion
Architecture should reduce fear of change. If every feature requires a meeting about side effects, the system is telling you the boundaries are wrong.
Architecture as a hiring question
A client hiring a software freelancer is also hiring a set of decisions that are annoying to undo. The right question is not "do you use microservices". The right question is "what will a second developer need to know in month four". Dhinova answers that in writing. The studio is in Kolkata. Clients in Mumbai, Delhi, Bangalore, Hyderabad, Chennai, and Pune stay on India Standard Time, so the review of a boundary can happen in business hours.
Keep the first system a modular monolith unless two teams must deploy on different days. Folders and modules are cheaper than a network of services. Split a service when a failure or a release cadence is already hurting you, not because a diagram looks mature. Business rules belong next to the write that must stay true. UI components should call a use case, not re-implement the rule.
Boundaries a freelancer should be able to draw
Name the domains that change for different reasons. Billing, identity, and the core job of the product should not share a junk drawer of helpers. APIs should follow the screen or the job, not a direct copy of every table. If the client can describe the user job in one sentence, the first module should match that sentence. Extra modules can wait for the next milestone.
Write a short decision record for auth, tenancy, file storage, and whether a slow task is queued. Future you, or the next freelancer, will not remember the Tuesday reason. A one-page note beats folklore. Include the option you rejected. That is the part people argue about later.
Performance and operations are architectural
A design that only works on a laptop in the office is not ready. Decide the expected data size for the first year and the page that must stay fast. Add logs, metrics, and a way to see errors before the launch week. You do not need a platform team. You need to know which request failed and whether the last deploy caused it.
The DevOps guide covers the release habit that keeps this structure deployable. Read it with this page. Architecture that cannot be released in a small step will be released in a risky one.
Where AI and mobile fit without a rewrite
An assistant, a web app, and a React Native client should share rules, not copy them into three prompts and three screens. Put the rule in one place the API enforces. Let the AI feature call that path, with a human check, instead of inventing a parallel truth. The notes on turning AI ideas into useful business features describe that feature. They are part of this system, not a detached experiment with its own database and its own login.
If the hire is specifically a site, an iPhone app, or an Android app, the service pages for a web freelancer, an iOS freelancer, and an Android freelancer state the launch bar. This article is the layer underneath those offers. A top freelancer in Kolkata or Mumbai still owes you a boundary, a record of the choice, and a demo that follows the same rules the code follows.
What to ask in the first call
What must stay true when data is saved? What can a second developer change without a meeting? What is deliberately postponed? How will you know a deploy went wrong? If those answers are concrete, the architecture is good enough to start. If every feature needs a meeting about side effects, the boundaries are already wrong, and no city label on the profile will fix that.
A small map the client can keep
Draw three boxes: who uses the product, what the product is allowed to save, and which outside system it calls. If a box needs a paragraph of exceptions, the boundary is still fuzzy. Revisit the map at the end of the first milestone and cross out what you did not build. The leftover is the next proposal, not hidden work. Dhinova uses that map on freelance builds so a client in any Indian city can see the system without reading the repository. It also shows where an AI feature is allowed to call in, and where it must not invent a second copy of the data.
Practices a client can point at
Software architecture design best practices are a map of who may change which data, not a poster on a wall. System architecture best practices add the dull part: what happens when a dependency is down, and how a new person reads the map six months later. A custom software development company in Kolkata should draw that map on the first call. Dhinova does this at dhinova.com, then builds only the boxes the first milestone needs.
Questions
What architecture question should I ask a freelancer?
Ask what a second developer must know in month four, what was postponed, and which rule is enforced when data is saved. Microservices are not the first question.
Should an AI feature have its own database and login?
No. It should call the same rules as the product and stay reversible. A parallel stack is how the assistant drifts away from the app you hired.
Related pages
- AI features inside the product
- Calm releases
- React web products
- Top freelancer in Kolkata and Mumbai
- Start a project
Tags: Architecture, Best Practices, Development, System architecture, Custom software Kolkata