Included
The stated software scope, product design, implementation, module tests, integration, delivery and recovery work. Uncertainty is carried in the hour range and blended rate assumptions.
Assessment methodology / BEG-ENG-20260905-01
Every figure needs
a visible basis.
A source census, a work-breakdown estimate, a functional inventory and a review of scoped verification records. Prepared with AI assistance and published by Bennett Edge Group on September 5, 2026.
Estimate explorer
Effort × delivery rate.
Scenario estimate
16,350 estimated hours × $130 per hour
Change the project or scenario to inspect the arithmetic. The detailed tables below remain available without JavaScript.
01 / Rebuild-cost method
Estimate the work required to reproduce it.
The estimate models a competent delivery team reproducing equivalent functional scope from requirements. It assumes mature frameworks, ordinary AI-assisted development tools, parallel work where practical, and the implementation, module testing, integration and delivery responsibilities listed below.
The lower and upper hour budgets reflect simpler and more demanding implementations of the assessed scope. Rates of $110, $130 and $150 per hour are assumed blended delivery costs, including compensation, benefits, management and delivery overhead. The central case uses the midpoint of the hour range and $130 per hour. These are planning scenarios, not statistical confidence bounds or supplier quotes.
For wage context, the U.S. Bureau of Labor Statistics reports May 2025 median annual wages of $135,980 for software developers and $104,300 for software QA analysts and testers. Those employee wages inform context; they do not establish the delivery rates used here. Read the BLS occupational data ↗
This is an owner-published, AI-assisted engineering assessment. It is not an independent appraisal, an audit of historical spending, or a company market valuation. Source volume informs scope; no dollars-per-line formula is used.
| Work package | Lower hours | Upper hours |
|---|---|---|
| Operating model, requirements & product design | 700 | 1,100 |
| Eight operating applications & module-level tests | 4,800 | 7,200 |
| Platform identity, access, entitlements & billing | 1,800 | 2,800 |
| Cross-application records, contracts & reconciliation | 800 | 1,400 |
| Payment-provider integration & failure handling | 800 | 1,400 |
| Hybrid continuity, synchronization & signed updater | 1,600 | 2,700 |
| Optional AI assistance & supervised management review | 600 | 1,000 |
| System integration, acceptance, deployment & recovery | 1,600 | 2,400 |
| Total estimated effort | 12,700 | 20,000 |
| Work package | Lower hours | Upper hours |
|---|---|---|
| Catalog, search, listing images & import workflow | 180 | 300 |
| Buyer identity, verification & account history | 140 | 240 |
| Cart, checkout sessions & stock reservation | 250 | 450 |
| Auctions, bidding & winning-bid checkout | 220 | 400 |
| Seller listing tools, order operations & reporting | 240 | 440 |
| Shipping, tax calculation & fulfillment context | 120 | 220 |
| Payment integration, webhook verification & retries | 200 | 360 |
| Interface, security tests, integration & release work | 350 | 650 |
| Total estimated effort | 1,700 | 3,060 |
02 / Interpretation
Replacement effort is one dimension of value.
Separate from the estimate
Third-party frameworks are reused. Ongoing hosting, support, transaction fees, customer acquisition, sales, legal/IP diligence, future features and the founder’s historical time are outside the model.
Commercial assessment
Company value also depends on verified revenue, retention, rights, liabilities, market position, transferability and strategic fit. Those inputs require a separate commercial review.
03 / Source census
A defined measurement, not an inflated file total.
The census reads the maintained source and counts nonblank physical lines, including comments, templates and styles. A byte-identical file is counted once across each project. Implementation source and verification source are separate categories; neither is a count of executed statements or a measure of test coverage.
HospiEdge includes canonical application source and shared system/delivery code. CDE includes application logic, configuration, migrations, maintained views/assets and delivery scripts. Exclusions include vendor packages, PDF/mail libraries, minified or bundled libraries, generated release/install output, caches, uploads, evidence archives, backups, prototype copies, data dumps and seed data. Known legacy application copies are excluded. Small framework scaffold files that remain in the maintained application can be included.
Classification uses file paths and extensions, followed by a review of large files and excluded categories. Some verification helpers may sit beside implementation code; counts should be understood as the stated source census. Formatting, comments, refactoring and generated-by-developer tooling can affect line counts. No claim is made that each line was manually written.
The report preserves census times, per-area and language totals, exclusions and a SHA-256 fingerprint of the private file manifest. Counts describe that recorded source snapshot; deployed versions and later source changes may differ.
Functional inventory / September 5, 2026
Relate the code to the work it supports.
The HospiEdge capability directory translates the supplied technical function inventory into application and workflow groups. Its companion entrypoint catalog was used as internal trace evidence: listed declarations were checked against the current routers and action registries, with an additional review of Ops navigation, routing and audit-processing code.
This source reconciliation supports the functional descriptions. It is separate from the dated acceptance records below, and does not turn individual routes, aliases or test handlers into a feature count.
Explore HospiEdge functions and connected workflows →04 / Verification accounting
State the scope of the confirmation.
HospiEdge evidence is drawn from dated acceptance receipts for signed identity, recovery rehearsal, release integrity, the installed updater and ordering. Receipt fingerprints and summaries are included in the downloadable assessment. Counts from separate suites are kept separate; historical runs are not represented as a fresh whole-product test.
CDE was tested on September 5 in a separate source copy with PHP 8.3, Laravel 13.12.0 and an in-memory SQLite database. Application environment files were excluded, payment gateways and mail used fixtures, and outbound socket/cURL execution was disabled. Production credentials, merchant accounts and customer data were not used.
| Run | Tests | Passed | Assertions | Follow-up |
|---|---|---|---|---|
| Unit | 11 | 11 | 29 | None in this run |
| Feature | 215 | 213 | 4,696 | Two copy-consistency assertions |
| Combined | 226 | 224 | 4,725 | Zero errors; two assertion failures |
Follow-up concerns the expected payment-setup sentence and configurable parent attribution on the Terms page. The CDE case highlights 184 tests in entirely passing suite groups; the table above includes every test attempted. Source inspection, fixture tests and recorded deployment acceptance provide different kinds of evidence and are labeled accordingly.
Let’s talk
Review the assumptions with us.
A deeper discussion can examine the measured snapshot, selected source, verification receipts, delivery approach and commercial diligence inputs.