Three sample reports

DevWatch / Project assessmentReport 01

Jan 2026 – Aug 2026 · Outside agency

AI answering & quoting for small businesses

Confidence: medium

Period score

72/100

Output across the full period

Difficulty

68/100

How demanding the work was

Quality

52/100

Assessment of the code

Findings

Issues & questions to follow up

Scores are AI estimates from code changes. Read the evidence and limits below.

The short version

A substantial product. Too much depends on one person.

The later work is careful and well tested. The next priorities are rotating exposed credentials and getting a second engineer familiar with the calls, payments, and deployment.

Built

An AI receptionist that can quote, book, and follow up.

Phone, email, and text agents; customer and admin dashboards; calendar, billing, and CRM integrations.

Improved

The most demanding work came with stronger tests.

The final stretch added two interchangeable voice providers and safeguards against duplicate calls and charges.

Needs attention

Secrets in history. Knowledge concentrated in one developer.

Committed credentials and certificate keys need rotation. Two agent tools also appear to call the wrong address.

What the code shows

The full analysis

Over seven months this repository went from empty to a working AI answering and quoting service for small businesses.

It now holds the screens customers use (dashboard, calendar, call and email inboxes, agent setup), a separate internal admin console for your own team, the behind-the-scenes systems that run everything, a public documentation site, and connections to a voice-AI provider and Twilio for phone calls, Stripe for billing, Google and Microsoft for calendars and mailboxes, and HubSpot and an industry CRM for pushing leads into customers' existing sales tools.

The biggest single pieces built were: a self-service signup and agent-training wizard; a quoting engine that prices moves from hourly, flat, mileage and hybrid rules including overtime, travel time and fuel; an AI agent that answers phone calls, texts and emails, books and reschedules jobs, and hands off to a human; and, in July, a system that lets you run the same phone agent on either of two voice providers and switch a customer between them safely while calls are in flight.

About 280,000 lines of hand-written change landed, alongside roughly another 277,000 lines of generated or copied-in content (automatically produced database and routing files, a vendor's email templates, encoded logo images) that does not represent original work and is excluded from the assessment. Nearly all of this came from one person, working under two email addresses, in concentrated bursts across 51 active days.

The last three months of work in particular is careful, well-tested engineering. The main concerns are that credentials and website certificate private keys were committed into the repository early on and remain in its history, that several very large single commits are effectively unreviewable, and that the project has no second pair of eyes on any of it.

Delivery over time

Selected weeks

A closer look at four weeks from the report. These are selected snapshots, not a complete timeline.

Week of Feb 9, 202685/100

Dashboard & agent foundations

The heaviest early week: a complete new dashboard (about 24,000 lines, part boilerplate), automatic synchronisation of the AI agent's instructions using a background job queue, fixes to social and email login, dashboard analytics built on database views, and deletion of the old 26,000-line web app. A run of trial-and-error deployment commits also sits here.

Week of Mar 30, 202685/100

A working quoting engine

Biggest week of the first half. The quoting engine landed with its own pricing rules (hourly, flat, mileage, hybrid, overtime, travel, fuel, minimum floors) and tests, metered access for outside software, usage reporting, service-type management screens in two applications, subscription plan management and a documentation site. Also a password reset fix and recovery of previously uncommitted database changes.

Week of Jun 8, 202688/100

CRM, email & calendar integrations

The largest week by delivered scope: dedicated HubSpot and an industry CRM lead delivery with a central lead create-or-update pipeline (about 28,000 lines), mailbox synchronisation for Gmail and Microsoft with an AI email agent that can quote and reschedule, a hand-written calendar replacing the third-party one, and dynamic pricing plans in signup. Includes a deployment safety check for the production database.

Week of Jul 27, 202692/100

Two voice providers, one call system

Exceptional week. One commit of about 81,000 lines introduced the switchable phone-call system with two voice providers, safeguards against processing the same call or charge twice, cost tracking, and real database and cache integration tests. On top of that: the admin organisations area rebuilt, staff impersonation for support, protection against a class of server-side request attacks, and repairs to lead delivery.

Reviewers rated this the most demanding work of the period.

Contribution & concentration

Who did what

Contributions visible in the repository. Hours are estimates of hands-on effort, not recorded time.

Developer A

about 99% of the difficulty-weighted work

Commits: 213
Active days: 37
Estimated hours: 850–1280

Built essentially the entire product over seven months: the customer dashboard, a separate internal admin dashboard, the behind-the-scenes systems, the database, and the integrations with a voice-AI provider, Twilio, Stripe, Google, HubSpot and an industry CRM.

Delivered the self-service signup and agent-training wizard, the quoting engine with its own pricing rules and metered access for outside software, the email and SMS agents with mailbox synchronisation, and the switchable phone-call system with the safety controls that stop calls or payments from being processed twice.

Also handled deployment, monitoring, backups, and a security hardening pass that added request throttling, tightened access to internal connection points, and signed the login handshakes with outside services. Roughly 26,000 lines of automated checks were added, most of them from June onwards.

Developer B

negligible, under 1%

Commits: 1
Active days: 1
Estimated hours: 0

One single-line change to an image on the signup page, on 7 February.

Evidence to act on

Findings 6

Some findings need a fix; others need a question answered. The detail distinguishes past issues, possible defects, and risks that still need checking.

01
Committed credentials
Passwords and secret keys were saved into the project's files where anyone with repository access can read them, and they stay readable in the project's history even after being deleted.
Reviewers found: a plaintext PostgreSQL password in docker-compose configuration (January, repeated later), a plausible real authentication secret in .env.example, a voice-AI provider webhook secret in backend source and in a WEBHOOK_TESTS.md file that was later deleted, Let's Encrypt certificate private keys (infra/nginx/ssl/privkey.pem, grafana-privkey.pem) committed and repeatedly replaced, a live quoting access key in scripts/quoting-test.md, provider-key-looking values and real phone numbers in examples/pooling-numbers.json, and a plaintext Prometheus authorization token in infra/monitoring/prometheus/prometheus.yml.
All of these should be treated as compromised and rotated.
02
Session data written to logs
For a period, the system wrote its own diagnostic output into logs including complete request headers, which can contain login session cookies. If those logs were retained anywhere, they could be used to impersonate users. This appeared in the login/authorization layer and the shared client code in February and was cleaned up during the May hardening pass, but the earlier deployment window is worth confirming with the developer.
03
Probable live defect
Two of the AI agent's abilities may be calling the wrong address and therefore silently not working. A configuration change on 24 July appears to have copy-pasted one address into the appointment-booking and text-a-link tool definitions, so both point at /api/tools/tally instead of their own connection points. Quick to verify and fix.
04
Unreviewable commit sizes
Some changes are too large for a second person to check. Several commits bundle a month of work into one submission, including one of roughly 81,000 lines covering the voice-call system, billing, database changes, admin screens and infrastructure at once. Reviewers also noted duplicate identical commits on 30 July, which usually indicates a mistake in how branches were merged rather than extra work.
This does not make the code wrong, but it means no one else has realistically reviewed it.
05
Volume inflated by generated and copied content
Reported line counts are much larger than the work behind them. Roughly 277,000 of the added lines are machine-generated or copied from elsewhere: automatically produced database type and routing files, a vendor's sample email templates complete with Notion/Stripe/Vercel images, duplicated AI assistant documentation stored three times over, and logo images encoded as text. These were excluded from the effort assessment.
06
Single-person dependency
One person holds all working knowledge of the system. Across 237 commits, all but one line came from a single developer using two email addresses. If that person becomes unavailable, there is no one with context on the phone-call handling, the payment flows or the deployment process.

Recommended action

What to do next

The work is real and, from late May onwards, of good quality. Two things are worth acting on.

First, commission a one-time security review focused on secrets: database passwords, a monitoring token, a live quoting access key, a service webhook secret and Let's Encrypt certificate private keys were all committed at various points between January and June. Removing them from current files does not remove them from history, so they should be rotated regardless of whether the repository is private.

Second, address the single-person concentration. One developer holds all knowledge of the phone-call system, the payment handling and the deployment process, and several commits (one of about 81,000 lines) are too large for anyone else to review. Getting a second engineer to read through the voice-call and Stripe handling, and asking for smaller commits going forward, would reduce the risk cheaply.

Beyond that, one small defect flagged by review is worth a five-minute check: two of the AI agent's tools appear to call the wrong address.

Coverage & uncertainty

Scope & limits

The counts describe the material reviewed. They are not a measure of developer productivity.

Commits reviewed: 237
Days with commits: 52 of 214
Contributor identities in the repository: 3
Lines added / removed: +280,208 / −102,358
Test lines added: 26,613
Generated or copied lines excluded from scoring: 277,510
Report confidence: medium

What this report can’t tell you

This report is an AI estimate built from the project's git history — every commit and its full code changes were reviewed. It is strong evidence, not surveillance truth: git does not show infrastructure work, code review, meetings, or debugging that ends in a small fix. Low scores are a reason to look closer, never proof on their own.

Contributor identities can include multiple email addresses for one person, owner accounts, and server accounts. They are not necessarily separate developers.

DevWatch / Project assessmentReport 02

Jun 2026 – Jul 2026 · Outside agency

Automated phone verification for businesses

Confidence: medium

Period score

88/100

Output across the full period

Difficulty

72/100

How demanding the work was

Quality

68/100

Assessment of the code

Findings

Issues & questions to follow up

Scores are AI estimates from code changes. Read the evidence and limits below.

The short version

A lot delivered in five weeks. Review it before scaling.

The difficult parts—live calls, security, and duplicate prevention—received real attention. An independent review and a consistent setting for real-time voice should come next.

Built

Phone verification, from the first call to the final report.

An AI agent handles menus, voicemail, and interviews, with email, SMS, and fax when a call fails.

Improved

Security and reliability received a substantial share of the work.

Signed notifications, encrypted transcripts, duplicate-call prevention, backups, and automated checks.

Needs attention

One developer built almost everything.

Get an independent review of calls and incoming notifications. Reconcile the conflicting real-time voice defaults.

What the code shows

The full analysis

Over about four and a half weeks, this repository went from an empty project to a substantially complete AI phone-verification product. One developer built almost all of it.

The system takes a verification request, places an automated phone call, navigates whatever it encounters (voicemail, call screening, hold music, press-1 menus, a human HR representative), runs a branching interview using an AI voice agent, records the outcome and transcript, and can also pursue the same verification by email, SMS or fax when a call fails.

Alongside that sits a staff dashboard for verifications, calls, campaigns, contacts and access keys, plus PDF verification reports, per-call cost tracking, and a way for other software to connect and submit verification requests directly. The last week added a real-time voice mode that talks to the caller with much lower delay than the earlier approach, and a mode that lets the whole system run inside someone else's product without its own login screens.

A significant share of the effort — roughly a week's worth — went into security and reliability rather than features: checking that incoming notifications from Twilio, a second telephony provider and an email-delivery provider are actually from those companies, encrypting personal data and call transcripts in the database, preventing the same person from being called twice, preventing a call from being recorded as finished twice, blocking scanner bots, daily database backups, and automated checks that run on every change.

That work is unglamorous and it is what separates a demo from something you can point at real customers.

Delivery over time

Selected weeks

A closer look at four weeks from the report. These are selected snapshots, not a complete timeline.

Week of Jun 22, 202688/100

The first working calling engine

Three active days but a huge amount of ground covered: the database design and its structured changes for around fifteen tables, sign-in and organization accounts, the first working API for contacts, campaigns and calls, background job workers, the Twilio phone integration with an AI voice agent, the dashboard skeleton, and local development setup.

Reviewers estimated 60-85 focused hours across the two slices in this window and rated the integration complexity moderate-to-high. Discounted somewhat because several commits were large scaffolding drops and a few would not have built on their own.

Week of Jun 29, 202685/100

Verification from end to end

Three active days covering the verification feature end to end, the staff dashboard for verifications, calls, campaigns, contacts and access keys, production deployment with automatic SSL certificates, and a long tail of real debugging against live phone behavior (signature checks behind the proxy, voicemail and call-screening detection, speech latency tuning). Reviewers put this at 50-70 hours of focused work.

Week of Jul 6, 202695/100

More channels. Stronger safeguards.

The heaviest week: 86 commits over five active days.

Timezone-aware calling windows, campaign rate limits and duplicate suppression, CSV contact import, outcome tracking, email/SMS/fax delivery channels, PDF reports, multiple AI providers with fallback, then a broad security and data-integrity pass (signature verification on incoming notifications, encryption of personal data and transcripts, duplicate-call and double-finish prevention, backups, automated checks on every change).

Reviewers rated the security and concurrency portions senior-level and estimated well over 100 hours across the slices. Some of the volume is automated reformatting and generated files, which is excluded.

Week of Jul 13, 202672/100

Lower-delay voice & embedded mode

One active day but high-value: the real-time voice mode built and debugged against Twilio's live protocol, per-call cost tracking, and a mode letting the system run without its own login screens for embedded deployments, with automated verification that the two halves stay separable.

Contribution & concentration

Who did what

Contributions visible in the repository. Hours are estimates of hands-on effort, not recorded time.

Developer A

about 99% of the difficulty-weighted work

Commits: 167
Active days: 14
Estimated hours: 270–390

Built essentially the entire product: the database and its structured changes, sign-in and organization accounts, the phone-calling engine that conducts AI verification calls (including voicemail detection, hold/IVR menu navigation, branching question flows, and a newer real-time voice mode), the delivery of verifications by email, SMS and fax, PDF report generation, and the staff dashboard covering verifications, calls, campaigns, contacts and access keys.

Also delivered the production deployment setup, daily database backups, automated checks that run on every change, and a large security and data-integrity pass covering signature checks on incoming notifications from Twilio, a second telephony provider and an email-delivery provider, encryption of personal data and call transcripts, duplicate-call prevention, and protection against scanner bots.

Closed the period with a real-time voice transport, per-call cost tracking, and a mode that lets the system run without the built-in login system for embedded deployments.

a production server account

well under 1% of the work

Commits: 1
Active days: 1
Estimated hours: 0–1

Made a single one-line change on a production server, switching the new real-time voice mode to be on by default when no explicit setting is present.

the owner

negligible

Commits: 1
Active days: 1
Estimated hours: 0

Created the repository with an initial one-line description file.

Evidence to act on

Findings 6

Some findings need a fix; others need a question answered. The detail distinguishes past issues, possible defects, and risks that still need checking.

01
single point of knowledge
Almost the entire product was written by one person with no review: 167 of 169 commits, no merges, no second author. Concretely this means bugs and security gaps have only one set of eyes on them, and the project would be difficult for anyone else to take over quickly. The code does carry unusually thorough internal documentation, which reduces but does not remove the risk.
02
security gaps present before being fixed
For a few days in early July, incoming notifications from the email, SMS and fax providers were accepted without verifying they actually came from those providers, and those notifications could mark a verification as complete. Reviewers also flagged that call-simulation test routes were mounted in the live system and that the fax handler fetched documents from URLs supplied in the incoming message (an avenue for probing internal systems).
All of these were closed on 2026-07-10 through 2026-07-11 with signature verification for Twilio, a second telephony provider and an email-delivery provider, protections against redirect and DNS tricks, and hiding the test routes in production. Worth confirming nothing was exposed during the window.
03
history not reliably buildable
Reviewers found several points in the history where code referred to functions that did not exist yet, meaning the project at those specific moments probably would not have built or started. Examples cited: a campaign scheduling function referenced by the queue workers, and the webhook delivery queue used by the verifications service one commit before it was added.
This is a symptom of large batches of work being split into commits after the fact, rather than a live defect, but it makes the history unreliable for rolling back to a known-good point.
04
production change made outside normal workflow
A one-line change on 2026-07-20 came from a server account (a production server account on a hosting provider machine) rather than a developer machine, and it flipped the new real-time voice mode to on-by-default. The deployment configuration still sets it to off, so the two now disagree. Small change, but production-adjacent edits made directly on a server are hard to audit.
05
credentials visible in the repository
Automated scanning found database passwords and one cloud access key inside files reviewed across several slices (reported as connection-string passwords and an AWS secret key, mostly in example and deployment configuration). Some of these may be placeholders, but they should be checked and rotated if real.
06
line counts inflated by generated and reformatted files
Two large commits (roughly 5,400 lines changed each, and several thousand more elsewhere) are mostly automated reformatting and generated database migration files rather than new work. These have been discounted in the scoring; the raw line counts overstate the amount of original code by a wide margin.

Recommended action

What to do next

The delivered product is broad and the hard parts (live phone calls, concurrency, security) were treated seriously. Two things are worth acting on.

First, this is a one-person system with no code review anywhere in the history; commission a one-time independent security and reliability review by a senior developer, focused on the phone-call handling and the incoming-notification paths, before onboarding real customers at volume.

Second, resolve the real-time voice mode default: the code now turns it on when nothing says otherwise, while the deployment configuration and documentation say it should be off until validated. Pick one and make them agree.

Coverage & uncertainty

Scope & limits

The counts describe the material reviewed. They are not a measure of developer productivity.

Commits reviewed: 169
Days with commits: 16 of 33
Contributor identities in the repository: 3
Lines added / removed: +53,038 / −14,612
Test lines added: 12,037
Generated or copied lines excluded from scoring: 48,531
Report confidence: medium

What this report can’t tell you

Contributor identities can include multiple email addresses for one person, owner accounts, and server accounts. They are not necessarily separate developers.

DevWatch / Project assessmentReport 03

Sep 2024 – May 2025 · Solo contractor

Revenue recovery, payments & invoicing

Confidence: medium

Period score

26/100

Output across the full period

Difficulty

65/100

How demanding the work was

Quality

28/100

Assessment of the code

Findings

Issues & questions to follow up

Scores are AI estimates from code changes. Read the evidence and limits below.

The short version

Real feature work. Security needs attention first.

A working recovery and invoicing product emerged from a sparse commit history. Exposed keys, weak encryption, and a potentially open email endpoint take priority over more features.

Built

Subscription recovery connected to real payment data.

Stripe customer imports, scheduled recovery emails, revenue analytics, and automatic PDF invoices.

Work pattern

Delivery was concentrated in a few short bursts.

52 commits on 10 days across the period. Estimated hands-on effort is 150–230 hours; this is not a timesheet.

Needs attention

Rotate credentials and review the payment paths.

Keys were committed repeatedly. The encryption key is in the code, and an email route appears unauthenticated.

What the code shows

The full analysis

Over about seven and a half months, one developer built the product from an empty repository into a working subscription-recovery product. The first commit (September 2024) put up the screens and navigation with placeholder data.

Then, after a five-month gap, the application was wired to real services: sign-in by emailed magic link, connecting a customer's Stripe account, importing their customer list with live progress feedback, and automated recovery campaigns with scheduled follow-up emails.

March 2025 added a real analytics dashboard (recovery rate, churn, revenue retention computed from actual payment events) and then a complete invoicing module that generates PDF invoices, emails them to customers, and can produce them automatically when Stripe reports a payment.

Early April was spent getting the application live in production, and the last two working days added switching between multiple connected businesses and finer control over campaign timing.

The work is real and the feature range is wide for one person. Two things temper it.

First, the calendar: 52 commits landed on 10 working days, with a five-month gap between September and February and long quiet stretches after. Expert review of the code estimates roughly 150-230 hours of hands-on effort in total, so this reads as an intense part-time project rather than sustained full-time development.

Second, quality hygiene is weak in a specific and urgent way. Live passwords and service keys were committed into the project files repeatedly, an encryption routine uses a key that is itself stored in the repository (so the encryption protects nothing), and reviewers flagged an email-sending connection point that appears to be open to anyone who finds it. Those need attention before anything else.

Delivery over time

Selected weeks

A closer look at four weeks from the report. These are selected snapshots, not a complete timeline.

Week of Feb 24, 202582/100

From mock screens to real services

The heaviest week of the period. The application went from mock screens to working software: email-link sign-in, Stripe account connection, customer list import with live progress, automated campaigns with scheduled follow-ups, and then a dashboard rebuilt on real payment data with churn and recovery metrics. Reviewers estimated 44-72 hours of work landing in these four commits across three days.

Week of Mar 10, 202558/100

Analytics built on payment data

One working day (March 10) delivering the analytics and charting overhaul, expanded Stripe payment-notification handling, and protection-rule statistics, plus same-day corrections to the revenue-retention calculations. Substantive full-stack work compressed into a single day.

Week of Mar 17, 202570/100

Invoices, PDFs & email delivery

Two days producing the invoicing module essentially from scratch: pulling payment events, generating invoices, producing PDFs, and emailing them through an email-delivery provider, with the supporting database structure and business-details settings. Fast and functional, though debug artifacts and an unauthenticated test-email route were left behind.

Week of Mar 31, 202545/100

Getting the product live

23 commits on April 6 taking the application live: automatic invoicing triggered by Stripe notifications, internal route protection, moving the project to the repository root, deployment configuration, and a long run of one-line production fixes. Low line volume but real work; a meaningful share of it was deployment trial and error.

Contribution & concentration

Who did what

Contributions visible in the repository. Hours are estimates of hands-on effort, not recorded time.

the developer

100% of the period's difficulty-weighted work

Commits: 52
Active days: 10
Estimated hours: 150–230

Built the entire product single-handedly: the initial screens and scaffolding, then the connections to Stripe, the email service, and the scheduling service that turned mock screens into a working application. Later work delivered the analytics dashboard (recovery rates, churn, revenue retention), the invoicing module with PDF generation and emailed invoices, automatic invoicing triggered by Stripe payment notifications, and the production deployment.

The final stretch added switching between multiple connected businesses and finer control over campaign timing.

Evidence to act on

Findings 6

Some findings need a fix; others need a question answered. The detail distinguishes past issues, possible defects, and risks that still need checking.

01
Committed live credentials (urgent)
Practical meaning: someone who finds these files could charge cards, read the customer database, or send email as the business. Reviewers found live-looking credentials committed in tracked environment files across at least four separate periods, including Stripe secret keys, a Supabase database password, an email-delivery provider/an email-delivery provider email tokens, a job-queue service scheduling tokens, and the application's auth secret.
Files named `.env`, `.env.actual`, `.env.defunct`, and `.the owner.env` were all committed at various points. Removing the files now is not enough; they remain recoverable from project history, so every key must be rotated.
02
Encryption that does not protect anything
Practical meaning: the customer Stripe keys stored in the database are not actually protected. In `lib/crypto.ts` the encryption key is written directly into the source code and a fixed salt is used, and the same key also appears in the committed environment file. Anyone with repository access can decrypt every stored key.
Separately, a Stripe notification-handling route was found writing decrypted secrets and API keys into server logs; some of that logging was later commented out, but not all of it.
03
Open email-sending route and leftover development shortcuts
Practical meaning: a stranger could potentially trigger emails from the business's account. Reviewers flagged `/api/invoicing/test-email` as appearing to have no authentication while being able to send mail through the configured an email-delivery provider token. A hardcoded development notification secret and a hardcoded temporary tunnel URL (ngrok) were also left in production-bound Stripe code.
04
Specific correctness bugs flagged in review
Practical meaning: connecting a Stripe account may not verify what the user typed, and could store the wrong key. In the original connection route, the code accepted an API key from the user but validated it against the server's own key instead. Reviewers also noted payment amounts stored in a database column type too small for realistic values, and a reference to the wrong data object in an email-alert function.
05
Database change history was rewritten mid-project
Practical meaning: the record of how the database has changed over time no longer matches reality, which makes future changes riskier and can cause a deployment to fail or corrupt data. Reviewers found older structured database changes deleted and later ones renumbered and recreated (migrations 0004-0009), leaving the code, the change journal, and the live database potentially out of step.
This should be reconciled deliberately rather than left to be discovered during a deployment.
06
Very large single commits and almost no automated tests
Practical meaning: it is hard for anyone (including a future developer) to verify or safely revise this work. Two commits alone account for the bulk of the product: the September launch and the February commit labelled 'Customer Import feature', which in fact rewrote authentication, the database structure, Stripe connection and notifications, email domain handling, campaigns, and most screens.
Across the whole period only one test file exists (406 lines), in a product that moves money and sends invoices. A read-only dashboard data route was also found writing corrections back into the database, which is a side effect that can surprise people later.

Recommended action

What to do next

Two actions, in order.

First, treat the committed credentials as compromised: rotate the Stripe keys, database password, and email service tokens, remove the secret files from the project's history, and replace the encryption routine whose key is stored alongside the data it protects.

Second, commission a one-time review by a senior developer covering the security items and the specific correctness bugs reviewers flagged (the Stripe key check that ignores the key the user typed in, the unauthenticated email route, the payment-amount columns that may be too small for real amounts, and the rewritten database change history).

Going forward, ask for smaller, single-purpose commits and at least basic automated tests around payments and invoicing; the current single test file gives no safety net for a product that handles money. The feature work itself is competent and delivered fast, so this is about hardening what exists rather than rebuilding it.

Coverage & uncertainty

Scope & limits

The counts describe the material reviewed. They are not a measure of developer productivity.

Commits reviewed: 52
Days with commits: 10 of 227
Contributor identities in the repository: 1
Lines added / removed: +41,517 / −11,416
Test lines added: 406
Generated or copied lines excluded from scoring: 56,529
Report confidence: medium

What this report can’t tell you

Contributor identities can include multiple email addresses for one person, owner accounts, and server accounts. They are not necessarily separate developers.

A substantial product. Too much depends on one person.

An AI receptionist that can quote, book, and follow up.

The most demanding work came with stronger tests.

Secrets in history. Knowledge concentrated in one developer.

Dashboard & agent foundations

A working quoting engine

CRM, email & calendar integrations

Two voice providers, one call system

Developer A

Developer B

Committed credentials

Session data written to logs

Probable live defect

Unreviewable commit sizes

Volume inflated by generated and copied content

Single-person dependency

What this report can’t tell you

A lot delivered in five weeks. Review it before scaling.

Phone verification, from the first call to the final report.

Security and reliability received a substantial share of the work.

One developer built almost everything.

The first working calling engine

Verification from end to end

More channels. Stronger safeguards.

Lower-delay voice & embedded mode

Developer A

a production server account

the owner

single point of knowledge

security gaps present before being fixed

history not reliably buildable

production change made outside normal workflow

credentials visible in the repository

line counts inflated by generated and reformatted files

What this report can’t tell you

Real feature work. Security needs attention first.

Subscription recovery connected to real payment data.

Delivery was concentrated in a few short bursts.

Rotate credentials and review the payment paths.

From mock screens to real services

Analytics built on payment data

Invoices, PDFs & email delivery

Getting the product live

the developer

Committed live credentials (urgent)

Encryption that does not protect anything

Open email-sending route and leftover development shortcuts

Specific correctness bugs flagged in review

Database change history was rewritten mid-project

Very large single commits and almost no automated tests

What this report can’t tell you