Test scope, screenshots, checkpoint findings and tier rationale were supplied by an identified reviewer. Identity is retained internally unless public attribution is explicitly enabled.
Guidepost
Guidepost is a technology-enabled diabetes coaching and care-management platform combining personalised coaching, patient data, analytics and AI-supported clinical insight.
Sandbox Africa checked the submitted evidence and promoted the verified checkpoint record. Any visible adjustment is identified rather than silently rewritten.
The official public tier and technical record below are the verified publication outcome.
Tier 2 — Market-Ready
Verified tier differs from submissionUpgrade to Tier 2. Current operating programme and platform evidence supports market readiness under the gated-clinical rule; direct enterprise assurance is still insufficient for Tier 3.
What worked: Public website accessible; company information available; website contact form available. What failed / remained inaccessible: Direct access to core diabetes-management service; self-service registration; public login; claimed WhatsApp chatbot. Errors found: No specific technical error was supplied; the principal blocker was limited access to the core service. Access limitations: No public account path; contact-form dependency; claimed WhatsApp service inaccessible; two websites with substantially the same information created uncertainty about the primary platform.
Why not one higher: Tier 2 would require stronger direct evidence of working core healthcare functionality, such as access to the diabetes-management or telemedicine workflow.
Verified findings and limitations
The intern could not self-serve into the full clinical programme, which is appropriately gated by healthcare and partner workflows.
Guidepost’s current official materials describe a long-running diabetes platform used by coaches, patients, healthcare providers and insurers, with technology-assisted interventions, analytics and stakeholder reporting.
No critical defect was established; the main limitation is legitimate programme access rather than product failure.
The intern did not directly operate the coach environment, patient data integrations or insurer workflows, and formal enterprise security controls were not audited.
What was actually assessed
Functioning website identified. No public sign-up functionality identified. No public sign-in functionality identified. Actual healthcare platform could not be directly accessed. Website form. Claimed WhatsApp service could not be accessed during assessment. Two different websites identified with substantially the same information; primary platform uncertain.
Edge on Windows 11
New public account
No public account path; contact-form dependency; claimed WhatsApp service inaccessible; two websites with substantially the same information created uncertainty about the primary platform.
What was observed
These images formed part of the evidence pack considered during verification. Full-standard records retain the contributor's factual caption for each screenshot.
Seven checkpoint assessment
The verified result is the official public checkpoint record. For earlier-standard reviews, these findings may have been reconstructed from preserved evidence during Sandbox Africa’s 2026 audit; they are not presented as if the contributor originally completed a structured worksheet. Contributor-submitted checkpoint wording is shown only where explicit public reviewer attribution has been enabled.
Step 1 — The Existence & Accessibility Check
Checking for dead links, infinite loading screens, or "Coming Soon" landing pages masquerading as live products.
Functioning website identified.
Can a user or enterprise actually sign up, or is it gated behind broken "Contact Sales" forms?
No visible self-service sign-up; contact form required; response wait; claimed WhatsApp service inaccessible; core service could not be directly evaluated. Editorial proposal adjusted from fail to partial using current independent verification and the established gated-product/safety-critical rules.
Verification adjustmentStep 2 — Functional Testing (The "Try It Out" Phase)
Does the application actually do what it claims to do? (e.g. a payment gateway completing a test transaction, a logistics app's routing engine working.)
Actual healthcare platform could not be directly accessed. Information could be viewed immediately, but the first working core healthcare action could not be reached without contacting the company. Editorial proposal adjusted from not_assessed to partial using current independent verification and the established gated-product/safety-critical rules.
Verification adjustmentAssessing the logical flow, responsiveness, and basic accessibility of the platform.
Moderate UX/UI design Evidence was not sufficient for a stronger conclusion in this assessment.
Verification adjustmentStep 3 — Technical & Architectural Assessment
Load speeds, uptime reliability, and basic stress responses.
Moderate Website performance Editorial proposal adjusted from partial to pass using current independent verification and the established gated-product/safety-critical rules.
Verification adjustmentAvailability, clarity, and functionality of API documentation and webhooks.
Not available publicly Editorial proposal adjusted from not_assessed to partial using current independent verification and the established gated-product/safety-critical rules.
Verification adjustmentSSL certification, basic encryption standards, and data handling transparency.
Not available publicly Editorial proposal adjusted from not_assessed to partial using current independent verification and the established gated-product/safety-critical rules.
Verification adjustmentRepresent Guidepost?
Claiming verifies company ownership and enables a response or additional evidence. It does not permit editing of the independent review.