Client progress
How our clients follow their project without asking for an update
Every client of ours can sign in and see where their project stands, in plain English, whether the work runs on our own tracker or in Jira. This is how it works, and how internal detail stays out of view.
Ayush Jain, Founder
Published
The system at a glance
- Progress
- Modules done out of all modules
- Read from Jira
- 5 fields only, cached for 5 minutes
- Client sees
- 8 latest updates, up to 12 milestones
- If Jira is down
- Last snapshot, marked Not live
What it replaces
Most small firms do this job by hand, with the tools already on the desk. This is that version, next to the system.
Without it
The usual version
- Clients call or message to ask where things are up to
- Someone stops work to check the task board and write a reply
- Updates go out in long email threads that are hard to find later
- Sharing the real task board shows clients comments and detail they were never meant to see
- The project begins once somebody notices the payment and remembers to set it up
With it
With the system
- The client's portal shows progress, what is in hand and what is done
- Updates meant for the client send an email and appear in their portal notifications
- Internal notes stay internal, enforced by the system
- If the work runs in Jira, the client sees a read-only summary, never the board itself
- The project is created automatically on the first confirmed payment
How it works
Step by step, in the order it happens.
The project sets itself up
The first confirmed payment creates the project, with its modules copied from the proposal the client accepted.
Choose where the work lives
An admin decides, client by client, whether the project runs on our built-in tracker or is mapped to a Jira project.
Update as the work happens
Each module is To do, In progress, In review, Done or Blocked, and the project is Active, On hold, Completed or Archived. Progress is simply the share of modules that are done, so nobody types it in.
Keep internal detail internal
Team updates can be marked internal-only. Internal notes are never shown in the portal and never sent to the client.
Tell the client
Changes the client should know about send an update email and appear in the notifications in their portal.
Read Jira carefully
For Jira projects, our server requests five fields: summary, status, issue type, last updated and due date. The client sees the progress percentage, to-do, in-progress and done counts, the eight most recent activity items and up to twelve dated milestones.
Stay calm when Jira is not
Results are cached for five minutes, with timeouts, retries and a circuit breaker. If Jira cannot be reached, the client sees the last known snapshot with a Not live badge and a plain-English message instead of an error.
Safeguards we built in
The parts nobody sees until something goes wrong. They are what make it safe to use with real clients and real money.
- The portal never talks to Jira; every request goes through our server
- Assignees, comments, descriptions and custom fields are never requested from Jira, so they cannot reach a client
- Internal-only updates are never shown to the client or emailed to them
- Every endpoint requires sign-in unless it is deliberately public
- Refresh tokens rotate on every use, and reusing an old one signs that person out of every session
- Only hashes of refresh tokens are stored
- If Jira is unreachable, clients see a labelled snapshot rather than an error or a blank page
The stack
- React portal
- ASP.NET Core API
- PostgreSQL
- Jira Cloud REST API
- Azure Communication Services email
What we learned
What building it taught us, and what we would tell anyone building the same thing.
- 01
Ask another system for the least you need. Requesting five fields from Jira, rather than everything, makes it impossible to show a client a comment they were never meant to read.
- 02
Plan for the day the other system is down. A labelled, slightly old snapshot keeps a client informed; an error page makes them pick up the phone.
- 03
Make progress a calculation, not an opinion. Done modules out of all modules is blunt, and a client can trust it because nobody types it in.
- 04
Private by default is easier than careful by habit. Marking an update internal-only is a switch the system enforces, not a rule the team has to remember.
The same visibility, built for your clients
If your team answers the same status question every week, the information already exists; it just has nowhere safe to be shown. We build the client view on top of the tools you already use, or give you a simple tracker if you do not have one.
Questions this usually raises
We already use Jira, Trello or another tool. Do we have to switch?
No. Ours reads from Jira on the server and shows clients a summary, and the same approach works with most project tools that offer an API. Your team keeps working where it already works; clients get a view built for them.
Can clients see our internal comments?
Not in the way we build it. In our system internal notes are marked as such and never shown or sent, and from Jira we never request comments at all. What a client cannot be sent cannot leak.