Insurance runs on paperwork that has to be right
A wrong date or amount on a policy document turns into an unhappy customer or a dispute. The app refuses bad data up front, and checks it again at the moment the document is made.
INSURANCE DOCUMENTS · C# / .NET · REACT
Sample Policy Documents
A practice system for one everyday insurance job: producing a policy document, getting a second person to approve it, and proving later exactly what was produced and who signed it off.
A portfolio project built around a fictional company with synthetic data. Every PDF it makes is stamped as a sample. No real insurer or customer is involved.
- Record a policy
- Generate a document in the background
- A different person approves it
- A newer version replaces the old one
- History keeps every step
// TRY IT (INTERACTIVE SIMULATION)
Switch between a business user, two approvers, an administrator and a read-only user, then generate, approve and break things. A checklist beside it guides you, and an activity log explains every rule the system applies. This is a simulation that runs in your browser with fake data. It is not the real application and it talks to no server. It mirrors the rules the real app is written to enforce, and refreshing starts it over.
The real app has not been run yet. Real screenshots will be added once it has.
// WHY I BUILT IT
These are the everyday problems in business software like this, explained without the jargon.
Paperwork gets changed after it is sent
If a policy is edited next month, you still need to know what the customer was actually given. Each document is locked to the exact policy data and wording version it was made from, so later edits can never quietly rewrite the past.
The person who makes it should not be the person who approves it
A basic control that managers and auditors expect. The server enforces it: you cannot approve your own document, even if you try to go around the screen.
When automation breaks, people need to see it
Documents are produced in the background. If one fails, it shows on screen with a plain reason and a Retry button. Pressing Retry, or asking twice, never produces a duplicate.
// WHAT A BUSINESS GETS FROM THIS DESIGN
These are the outcomes the design is built to deliver. They are design goals, not measured results: nobody has used this in a real business.
Fewer wrong documents going out
Invalid data is stopped before a PDF exists, and a draft made from out-of-date policy data cannot be approved.
Disputes can be answered with evidence
For any document you can show what data and wording it used, who generated it, who approved it and when, and prove the stored file has not been altered.
Controls a reviewer can check
Separation of duties, an edit-proof history, and one current approved document per policy, enforced by the database and not only by the screens.
Less time chasing silent failures
A failed job is visible with its reason. Staff do not have to ask IT whether a document went out.
Safe to change
Wording changes are published as a new template version. Old versions and the documents made from them stay exactly as they were.
People see only what they need
Four roles. Read-only users cannot see drafts, and customer email addresses are masked for them. Logs hold reference numbers, not customer details.
// WHAT IS BUILT, AND WHAT IS NOT VERIFIED
Built
- The application, its database design, the PDF generation, the role rules and the screens are all written
- A suite of 45 automated test cases is written, covering permissions, approval rules, duplicate requests, failure recovery, document history and logging
- Every document and screen is labelled as a sample, and all data is synthetic
Not verified / limits
- The code has not been compiled or run yet, so the tests have not been executed. It was written for a cloud workspace and is waiting for its first build there
- No business results are claimed: there are no real users, no time-saved figures and no costs measured
- Uses SQLite as a stand-in for SQL Server. Moving to SQL Server is documented but not done, and SQL Server tuning skills are not shown here
- Only document generation is built. Incident handling, release management, reporting and integrations are separate pieces not built yet
This is a demonstration, not a production-ready system.