01SaaS · Multi-role writing SaaS

Xpress Writers

A customer-facing marketplace connecting clients with expert writers — real-time orders, role-based dashboards, and workflows a non-technical team can run.

Open xpresswriters.in All case studies

Xpress Writers was designed and engineered by Yuvraj Singh, Forward Deployed Engineer.

Xpress Writers product — dark marketplace landing page beside an orders dashboard — Product interface · Xpress Writers

Role: Full-stack engineer — end-to-end architecture, REST APIs, the real-time layer, and the role-based dashboards
Timeline: Live at xpresswriters.in. No engagement dates are published for this build, so none are stated here.
Stack: JavaScriptTypeScriptReact.jsNext.jsNode.jsExpress.jsSocket.IO

01Context

The problem

Xpress Writers is a marketplace where clients commission written work and writers deliver it. Three kinds of people touch the same order — the client who placed it, the writer producing it, and the operations staff keeping it moving — and each needs a different view of the same record. The product had to be something a non-technical team could run day to day, which rules out any workflow whose next step is asking an engineer.

Constraints(04)

Clients, writers, and operations staff read and write the same order records under different permissions.
Order state has to look current on every open dashboard without anyone pressing refresh.
Non-technical staff run the product day to day, so a step that needs an engineer is a defect.
It is a live, customer-facing product — every change lands against real orders.

02Scope

What was built

01
Client ↔ writer matching and order lifecycle
02
Role-based dashboards for ops and freelancers
03
Live chat that keeps the workflow moving

03Architecture

The system

A React.js and Next.js product surface sits on Node.js and Express.js REST APIs, with Socket.IO carrying anything that has to move while you are watching it. The API is the boundary that owns authentication, role permissions, and the order lifecycle, so the dashboards are views over state rather than owners of it. Each role gets its own dashboard composed from the same order records: client, writer, and operations read one source of truth through three sets of permissions.

Next.js frontend with Express API boundaries
Socket.IO for real-time conversation state
REST APIs shaped around multi-role permissions

04Decisions

What was chosen, and what it beat

A decision with no rejected option is a feature list. Each one below carries the alternative that was actually on the table and the reason it lost.

Decision 01 / 03Xpress Writers
Push order and chat state to open dashboards over a Socket.IO connection.
Rejected
Polling the orders REST endpoint on a timer from every open dashboard.
Why this won
A client, a writer, and an operations user can all be looking at the same order at once. Polling multiplies identical reads by the number of open tabs and still shows state that is one interval stale; a socket sends each transition once, to the people subscribed to that order. REST stays the source of truth for first load and for anything a reconnect has to recover.
Decision 02 / 03Xpress Writers
Enforce role permissions in the Express API and let the dashboards render whatever comes back.
Rejected
Deciding what each role can see inside the React components that draw the dashboards.
Why this won
Three roles read overlapping order records, so a hidden button is not a permission — the underlying request still exists and can still be made. Keeping the check at the API boundary leaves one place to open when the question is who is allowed to do this, and it means a new dashboard cannot accidentally ship a wider view than its role allows.
Decision 03 / 03Xpress Writers
One order lifecycle shared by every role, rendered three ways.
Rejected
Building a separate client product and writer product, each with its own order records.
Why this won
The order is the thing that moves between the roles, so splitting it into two products would mean two copies of its state and a synchronisation problem in the middle. One lifecycle with per-role views is also what lets operations step into any order directly, instead of an engineer exporting a record from one side to the other.

05Status

Where it stands

Live and customer-facing at xpresswriters.in.
Clients, writers, and operations each work from their own dashboard over a shared order lifecycle.
Real-time chat and live order updates run over Socket.IO in production.
Operations staff run the order workflow without engineering involvement.

See it running at xpresswriters.in

06Questions

Xpress Writers, answered

What is Xpress Writers?

Xpress Writers is a writing marketplace SaaS that connects clients with writers. It covers the order lifecycle end to end — placing an order, matching it to a writer, discussing the work in real-time chat, and tracking it through to delivery — with a separate role-based dashboard for clients, writers, and the team running operations. It is live at xpresswriters.in.

Who developed Xpress Writers?

Yuvraj Singh developed Xpress Writers. He designed its end-to-end architecture and built the React.js and Next.js front end, the Node.js and Express.js REST APIs, the Socket.IO real-time layer, and the role-based dashboards. Yuvraj Singh is a Forward Deployed Engineer who builds full-stack and AI systems.

What technologies does Xpress Writers use?

Xpress Writers is built in JavaScript and TypeScript, with React.js and Next.js on the front end and Node.js with Express.js behind the REST APIs. Socket.IO carries real-time chat and live order updates. Role permissions are enforced in the API rather than in the interface, so the dashboards render state the server owns.

What problem does Xpress Writers solve?

Commissioning written work involves at least three people with different jobs — the client who ordered it, the writer producing it, and the team coordinating both — who all need the same order to stay in sync. Xpress Writers puts them on one order record, gives each role only what its permissions allow, and keeps status live instead of requiring a refresh or a chasing message. Operations staff run that workflow themselves, without engineering help.

Related work