digiQC is a digital quality-control platform for construction and infrastructure. Teams inspect on the mobile app and monitor on the web. It covers the full quality cycle — inspections (Inspect), site issues (Issue), and record registers (Register) — with checklists, photographic proof, approvals, and reporting.
This article explains who benefits, the industries it serves, its modules, and its full feature set — with real examples — and answers the common "can digiQC do this?" questions.
Project Owners / Developers — see real-time quality across all sites without being on site, get assurance that work meets spec before releasing payment, and keep a complete audit trail for handover and disputes. For RERA-regulated real-estate projects, digiQC provides the documented, photo-backed quality evidence that RERA compliance, buyer handovers and possession demand — turning quality from a claim into a verifiable record.
General Contractors — standardise quality control across trades and sites, enforce checklists, track sub-contractor performance, and cut rework by catching defects early with evidence.
Trade / Sub-contractors (Associates) — get a clear checklist of what's expected, raise RFIs when work is ready, respond to issues assigned to them, and keep photo proof of completed work.
Consultants / PMC (Project Management Consultants) — perform independent inspection and sign-off, approve remotely, audit the work, and report to the owner with a defensible record.
Solar / renewable-energy organisations — run QC for solar EPC: module-mounting, cabling, earthing and torque checklists across many distributed sites, with geo-tagged photographic evidence and remote commissioning approvals.
Infrastructure & EPC companies — manage quality on large, multi-site projects with standardised checklists, staged inspections and multi-level approvals.
Government bodies / PSUs (indirect) — their contractors and consultants use digiQC on government projects, so the authority gets standardised quality, photographic evidence and a full audit trail without any extra effort of its own.
Building & real estate · roads & highways · bridges, flyovers & ROBs (road-over-bridges) · railways & metro · solar & renewables · water & utilities · industrial plants · public buildings — schools & stadiums.
Inspect — quality inspections against checklists (EQC), with RFIs and multi-level approvals.
Issue — raise, assign, respond to and close site issues (NCRs / snags), including cost of quality.
Register — log-based records (material tests, pour registers, etc.) with approvals and export.
Web admin — set up the organisation library, projects, users, teams and reports.
Customisable checklists — Build quality checklists tailored to each activity, with your own stages, checkpoints, answer types and pass/fail rules, so inspections follow your organisation's exact standards rather than a generic template. Example: create an "RCC Footing Pour Card" with checkpoints such as "Reinforcement diameter & spacing as per drawing", "Clear cover maintained with cover blocks" and "Formwork line, level & rigidity checked" — each set to require a photo, so the steel is documented before the pour is allowed.
digiQC template library — Adopt ready-made, industry-standard checklists and use them as-is or tweak them, so you don't build every checklist from scratch. Example: pull a standard "Brick Masonry" checklist into your project, add two checkpoints specific to your specification, and activate it in minutes.
CSV import — Create an entire checklist's stages and checkpoints in bulk from a spreadsheet instead of adding points one by one. Example: an MEP checklist with 80 checkpoints across 5 stages is prepared in Excel and imported in a single upload, ready to inspect.
Multi-stage checklists — Inspect one activity across sequential stages, each with its own checkpoints and approvals, matching how work actually progresses on site. Example: an RCC element is inspected first at the "Reinforcement" stage (before concrete) and again at the "Pouring" stage, so nothing is buried without a check.
Checkpoint types — Capture each check in the most suitable form: Yes/No, Numeric (with values/tolerances), Text, or Option (choose from a list). Example: "Concrete slump (mm)" is a Numeric checkpoint where the inspector records the measured value, while "Surface finish" is an Option checkpoint (Good / Average / Poor).
Mark-for-QC-fail — Define exactly which answer fails the stage, so a critical defect automatically flags the inspection instead of relying on the inspector's judgement. Example: set "Honeycombing observed? = Yes" as the QC-fail answer — the moment Yes is selected, the stage fails and a re-inspection is triggered.
Mandatory photo / remark — Force a photo and/or a written remark on any checkpoint, so no critical check can be signed off without evidence. Example: the "Reinforcement as per drawing" checkpoint requires a photo — the inspector can't complete the stage until a live picture of the steel is captured.
Reference guidance (bulb) — Attach reference text, links or photos to a checkpoint; the inspector sees a bulb icon and taps it for guidance while inspecting, reducing errors. Example: on "Clear cover", attach the drawing note "cover = 50 mm ± 5" so the inspector checks against the right tolerance on the spot.
Additional points — Add an ad-hoc checkpoint during an inspection when the site throws up something the checklist didn't cover. Example: the drawing calls for an extra chamfer not in the checklist, so the inspector adds it as an additional point and photographs it.
Nomenclature — Give every inspection a structured, consistent name/location built from your project's hierarchy, so records are easy to find and report on. Example: an inspection is named "Tower-A / Floor-3 / Flat-301 / Living-room", making it instantly traceable months later.
Offline capture — Inspect fully offline where there's no signal; data and photos are stored on the device and sync automatically once back online. Example: an inspector records a full basement inspection with photos in a no-network area, and everything uploads when signal returns.
Real-time witness photos — Photos can only be taken with the live camera (no gallery uploads), so every image is a genuine, current record of the work. Example: the poured-slab photo must be shot on the spot — an old picture from the gallery can't be attached.
Geo-tagged inspections & issues — Each inspection and issue is geo-tagged with its location and time; because only live-camera photos are allowed, every photo is inherently captured at that verified place and time. Example: a dispute over whether Block-C was inspected is settled by the inspection's embedded location and time, backed by its live photos.
RFI (Request For Inspection) — The contractor formally requests an inspection when work is ready, and the inspection proceeds only after that request — mirroring the site RFI process. Example: once the slab reinforcement is complete, the contractor raises an RFI and the QC engineer is notified to inspect.
RFI approver & Re-RFI — An RFI can require an approver to accept or reject it before inspection, and on a fail a fresh RFI (Re-RFI) restarts the cycle after corrections. Example: the PMC approver rejects an RFI raised prematurely; the contractor rectifies and raises a Re-RFI.
Multi-level approvals (L1–L3) — After a pass, up to three approvers sign off in sequence before the stage completes, matching site hierarchies. Example: a passed slab inspection goes site-engineer (L1) → project-manager (L2) → client (L3), each approving in turn.
Site & Remote approval — Choose how an approval is given: Site approval requires the approver to be on site, approving from the mobile app; Remote approval lets them approve from anywhere, on web or mobile. Enforce presence where it matters, move fast where it doesn't. Example: a critical pour uses site approval (the engineer must be present); a routine finish uses remote approval from the office.
Auto-pass / approve-with-comment — A passed inspection auto-completes the stage unless an approver deliberately approves-with-comment, which keeps it flagged for attention. Example: routine passes flow through automatically, but an approval with the comment "watch the cold joint" keeps that EQC highlighted.
Witness & drawing checks — Require a witness sign-off or a reference drawing at a stage, enforcing procedures where a third party or drawing must be present. Example: a stage is set to require the client's witness before it can pass.
Full issue lifecycle — Raise, assign, respond to, verify and close site issues (NCRs / snags), with a clear trail at each step. Example: cracked plaster is raised, assigned to the contractor, who responds with a repair photo; the raiser's team verifies and closes it.
Types & tags — Classify each issue by type (Quality, Safety, Material, Others) and add tags for area, priority or problem type, so issues can be filtered and analysed. Example: a fall-hazard is raised as "Safety" and tagged "Zone-B / Priority-High" for quick filtering in reports.
EQC-fail → NCR — Raise a formal NCR (issue) directly from a failed checkpoint, linking the defect to the inspection; the inspection continues only once that NCR is closed. Example: a failed waterproofing check spawns an NCR that must be resolved before the stage proceeds.
Cost of Quality — Record the cost of an issue — labour, material, machinery and other — plus its root cause and corrective action, quantifying the cost of poor quality. Example: redoing a defective plaster patch is logged with labour + material cost, root cause "poor mix", corrective action "revised mix approved".
Log-based records — Maintain structured registers for repetitive records that aren't checklist inspections. Example: a cube-test register logs each sample's ID, casting date, testing date and 28-day strength.
Computations & multi-stage approval — Registers can auto-calculate values and route entries through approvals, then export to a report. Example: a pour register computes total concrete volume and is approved by the engineer before export.
Geo-fencing (radius) — Inspections can be restricted to within the project's set radius, so they can only be done at the actual site. Example: with a 200 m radius, an inspector standing off-site can't start or submit an inspection.
Device authentication — Require a phone unlock (biometric / PIN) before an inspection, tying the record to the authenticated device holder. Example: the inspector must pass Face ID before each inspection.
Role-based access — Assign roles (System Admin, Project Admin, Inspector, Approver, Auditor, Associate) with rights per project, so each person only sees and does what their role allows. Example: an Auditor can review and comment but not conduct inspections.
Organisation library — Users, teams and checklists live at organisation level and are imported into any project, so setup is fast and consistent. Example: a standard "Finishing works" checklist is imported unchanged into every new tower project.
Multi-project / multi-org — One user account works across many projects and even multiple organisations that use digiQC. Example: a consultant inspects on three different developers' projects with one login.
Time-zone stamping — All date/time stamps follow the project's time zone, keeping records accurate across regions. Example: a project in another time zone shows inspection times in local time.
Secure cloud storage & audit trail — Data and photos are stored securely in the cloud with a full record of who did what and when. Example: months later, you can see exactly who approved a stage and at what time.
Target vs Achieve — Set a weekly inspection target per project and track the actual final-passes against it in real time. Example: a target of 20 final-pass EQCs this week updates live as the site completes them, with a CSV of the week's inspections.
Analytical reports & dashboards — Get quality insights and trends across projects for leadership monitoring. Example: a dashboard shows pass rates and open NCRs by project.
EQC & issue reports — Download CSV logs and PDF reports, or send a QC-report link on email, filtered by date range. Example: export a month's EQC log to CSV, or email the final QC-report links to the client.
Report configurator — Customise what the EQC PDF report contains and how it looks. Example: add the organisation logo and choose which fields print on the client report.
Searchable history — Find any past inspection or issue quickly. Example: search all "waterproofing" inspections in Tower-B last quarter.
Instant notifications — WhatsApp + in-app notifications keep everyone updated on assignments, responses and approvals. Example: an assigned contractor gets a WhatsApp the moment an issue is raised to them.
Identify training needs — Recurring failures surface where teams need training. Example: repeated failures on "cover blocks" flag a toolbox-talk need.
Yes. Every checkpoint has an "EQC Photo Required" (and "Remarks Required") setting. When it's on, the inspector cannot complete that checkpoint or the stage without a live, camera-only photo, which is geo-tagged and time-stamped. How to set it up: open the project's checklist → edit the checkpoint → turn on EQC Photo Required (and Remarks Required if a note is also needed). Every future inspection of that stage then carries the photo as mandatory evidence.
Yes. digiQC supports offline inspection. Before going to a low-network area, the user opens the project once while online to cache its data; they can then inspect and capture photos fully offline, and everything syncs automatically when connectivity returns. Note that new server-side changes won't show until back online, and a next stage that needs approval must sync first. How to set it up: open the project online to cache it, work offline, then let it sync (or use the Sync tab).
Yes. Remote approval lets an approver review the inspection (answers, photos, remarks) and Approve or Redo from web or mobile, wherever they are. Up to three approval levels (L1–L3) can be configured per stage, and RFIs can have their own approver too. How to set it up: set the number of approval levels on the checklist stage and assign approvers; they act from their To Do list.
Yes. Approval can be set to Site approval, where the approver must be on site and approve from the mobile app — used for critical activities where presence matters. (The alternative is Remote approval, from anywhere on web/mobile.) How to set it up: choose the approval mode (Site vs Remote) for the stage/approver.
Yes. Inspection workflows are configurable — turn RFI on/off, add an RFI approver, set 0–3 approval levels (L1–L3), enable Re-RFI, and require witness/drawing — so the checklist follows your organisation's exact approval process. How to set it up: configure RFI and approval levels on the checklist stage (see the RFI & workflow articles).
Yes. Workflow settings are per stage, so different stages of the same checklist can follow different flows. Example: the reinforcement stage requires L1–L3 approval, while a minor stage just needs a pass. How to set it up: configure each stage independently.
Yes. A project can run many workflows at once — different checklists and stages can each have their own RFI/approval configuration, and add-ons (RFI, EQC-fail→NCR, etc.) are set per project. How to set it up: configure per checklist/stage; enable add-ons in project permissions.
Yes. The Cost of Quality feature records, when an issue is closed, the cost incurred — labour, material, machinery and other — plus the root cause and corrective action. How to set it up: enable Cost of Quality (a paid add-on); the System Admin adds the cost when the issue is closed.
Yes. You can bulk-import users, teams and checklists via CSV, bulk-add checkpoints to a stage, bulk-configure multiple checklists at once, and multi-select checkpoints to edit or delete together. How to set it up: use the Import / Bulk Add / bulk-configure options in the Setup tab and checklist editor.
Yes — through the Register module. Create a register (e.g. a cube-test or material-test register) that logs each entry, auto-computes values, routes through approvals, and exports as a report. How to set it up: create a register template for the test in the Register module.
Yes. From the Report tab you can download a CSV log or PDF report, or email a QC-report link, in one click after choosing your filter and date range. How to set it up: Report tab → set filter/date range → download or email.
Yes. Inspect gives EQC Log, Latest Log and Count CSVs; Issue gives Instruction Detailed and Latest Log; Register exports its records — all by date range. How to set it up: use the Report tab (Inspect/Issue) and Register export.
Yes. CSV logs, configurable PDF EQC reports (with your logo, via the Report Configurator), and a QC-report link on email provide a defensible record for audits and clients. How to set it up: Report tab + Report Configurator.
Yes. Beyond the standard analytics, digiQC offers customised dashboards on request — e.g. a leadership quality dashboard tailored to your organisation's hierarchy and reporting needs. How to set it up: request a custom dashboard from the digiQC team.
Yes. Set the project's location and radius on the map (geo-fencing), and use nomenclature zones so every inspection is tied to a structured location — enabling location-wise analysis in reports and dashboards. How to set it up: set the radius on the project and configure nomenclature zones.
No — and that's by design. Every inspection, issue and register entry is authenticated, time-stamped and immutable — once submitted it cannot be edited or deleted. This guarantees a tamper-proof, audit-grade record. (You can add further stages, responses or comments, but the recorded entry itself never changes.)
Yes. digiQC is role-based — each user has a role (System Admin, Project Admin, Inspector, Approver, Auditor, Associate) and per-project rights (location, authentication, web access, raise-instruction, and which checklists/RFIs they can operate). How to set it up: set the role and rights in the project's User tab.
Yes. A user's Web Access can be set to Team (they see only their team's data) or Project (they see the whole project), and they can be assigned specific checklists and RFIs — so people get exactly the data access you intend. How to set it up: set Web Access (Team/Project) and assign checklists/RFIs in the project's User tab.
Yes — through three controls used together. Geo-fencing restricts inspections to within the project radius; real-time camera-only photos (no gallery) are each geo-tagged and time-stamped; and device authentication can force a biometric unlock before inspecting. Together these ensure the inspection was done at the site, at the time, by the right person. How to set it up: enable Location and Authentication in the project's permissions and set the radius on the map.
Yes. With RFI enabled on a checklist stage, the contractor (maker) raises a Request For Inspection when work is ready; the checker is notified and inspects only after that request. An RFI approver and Re-RFI (a fresh RFI after a fail) can also be configured. How to set it up: turn on RFI for the project, then enable it on the relevant checklist stage.
Yes. The Cost of Quality feature records, when an issue is closed, the cost incurred — labour, material, machinery and other — plus the root cause and corrective action. This quantifies rework cost and supports analysis. How to set it up: enable Cost of Quality (a paid add-on) on the project; the System Admin adds the cost details when the issue is closed.
Yes. Checklists are created once at organisation level (the organisation library) and imported into any project, so every project starts from the same standard. Editing a library checklist doesn't change already-imported project copies — you re-import to update. How to set it up: create and activate the checklist in the Setup tab; inside a project, use Import to pull it in.
Yes. digiQC produces CSV logs (EQC log, latest log, count), PDF EQC reports, and can email a QC-report download link filtered by date range; issue reports (detailed and latest) are available too. The PDF is customisable via the Report Configurator and carries your organisation logo. How to set it up: use the Report tab (filter + date range) to download or email; configure the PDF via the Report Configurator.
Yes. Role-based access gives each user a role (System Admin, Project Admin, Inspector, Approver, Auditor, Associate) and per-project rights — location, authentication, web access, raise-instruction, and which checklists/RFIs they can operate. How to set it up: set the user's role and rights in the project's User tab.
Yes. Target vs Achieve lets a project admin set a weekly target of expected final-pass EQCs and see the achieved count update in real time, with a CSV of the week's inspections. How to set it up: open the project's Target tab and set the week's target.
Yes. Nomenclature builds a structured name for each inspection from your project hierarchy (e.g. tower / floor / flat / room), making records consistent and easy to find and report. How to set it up: configure the nomenclature zones at project level; inspectors pick the location when starting an EQC.
Yes. With EQC-fail → NCR enabled, a failed checkpoint can directly raise an NCR (issue); the inspection can continue only once that NCR is closed, tying defects to corrective action. How to set it up: enable the EQC Fail → NCR add-on on the project.
Less rework — defects caught early, with evidence.
Faster approvals — remote and multi-level.
Fewer disputes — photo proof and a full audit trail.
Standardised quality — across sites and teams.
Greater accountability & visibility — for owners, consultants and contractors alike.
digiQC covers the full quality cycle — Inspect, Issue, Register — on mobile + web.
It benefits owners/developers (incl. RERA), contractors, consultants, solar and infrastructure/EPC firms, and — indirectly — government/PSU projects through their contractors & consultants.
Core strengths: evidence-based inspections, RFIs & multi-level approvals, issue tracking with cost of quality, offline capture, geo-fencing, and rich reporting.
Records are authenticated, time-stamped and immutable — inspections/issues can't be edited or deleted, giving an audit-grade trail.
1.1 Introduction
1.3 Types of users & roles
2.2.1 How to start a new Inspection/EQC?
2.3.1 How does an issue work? (flow & cases)
