A Quality Dashboard Must Show the Questions Left Out of Its Scores

Reviewed by Victor Sineglazov on October 22, 2026.

A quality dashboard can show a percentage while hiding which questions never contributed to it. In our admin interface, the important change was to place excluded results beside the metrics and make individual outcomes inspectable. A number without its run population was too easy to misread.

The product used a bounded evaluation set for answers from a medical learning corpus. My frontend work connected the dashboard to the evaluation contract. The scoring engine belonged to the backend. This case concerns how its results became visible without treating a scorecard as evidence of clinical performance.

Replace a demonstration value with a run

During the prototype stage, metric cards could display demonstration scores. The integrated screen needed a run identity, recorded model and duration, plus a distinction between a completed run and the absence of one. Before any run completed, the interface said so.

We also showed failed runs and their reasons. A run that did not complete could not be made to look successful by retaining a favorable metric from a different state. The user needed to know which result set the cards described before opening a detailed answer. That requirement linked the history list, progress display and result sheet. A loading indicator alone could not explain whether the model was waking, questions were being answered or execution had failed. The recorded implementation exposed those states separately.

Put excluded outcomes beside the score

The frontend represented a null metric with a dash glyph, rather than converting it into zero. It separately displayed skipped and error counts with an explanation that they were left out of the scores. The contract's population mattered as much as its arithmetic.

This presentation does not make excluded questions unimportant. It makes their absence inspectable. A reviewer may decide a benchmark has a coverage problem even when the score over its included results looks favorable.

A refusal needed a different fact display

The result sheet showed the question, expectation and individual facts, with found or missing markers where applicable. A refused answer left those fact markers unset. We did not paint an unattempted fact check as a set of missing facts or a successful factual answer.

A question whose document had disappeared also needed an explicit unavailable state. It could remain relevant to the run history even when the current source could no longer be opened. Removing its row would make the evaluation population harder to reconstruct.

The detailed sheet exposed the answer and citations alongside unsupported-number findings, a verdict note and the recorded model and duration. These fields gave the reviewer material to inspect after seeing a metric. They did not independently validate the checker that produced the findings.

The fixture made an attractive percentage insufficient

The metric-card regression supplied a synthetic completed run with 21 skipped questions and one error. It asserted an explanatory line beside the cards stating that those outcomes were left out of the scores. A second fixture with no excluded outcomes expected no such line. These numbers belong to a presentation test, not a report of the production model's coverage.

const latest = runSummary({
  id: 'run-3',
  number: 3,
  metrics: { ...RUN_2.metrics, skipped: 21, errors: 1 },
})
// The cards must expose both excluded counts beside the scores.

Another test set a metric to null and expected no trend text for that card. The other metrics could still compare with the preceding completed run. This rejected a convenient but misleading fallback that turns an absent denominator into a numerical zero and then computes an apparent change from it. Direction and quality were separate in the trend assertions. A falling hallucination rate was presented as better; a falling accuracy score was worse. One shared rule that paints every downward number as bad would reverse the meaning of a rate whose desirable direction is lower. The card needed the metric's semantics as well as the arithmetic difference.

The detailed sheet had to preserve reasons for abstention

The skipped-result fixture carried SOURCE_GONE, no answer and no citations. Its sheet exposed the reason and a neutral skipped state, without a passing label or empty answer and citation regions that looked like a scored response. Switching that fixture to ERROR produced the error tone and recorded error note instead.

A refused ordinary question supplied a different combination: the outcome could be failed while the individual expected facts remained unmarked. The test checked the absence of both found and missing fact markers. It did not use the missing-facts collection alone as permission to display a factual comparison for a claim the answer never attempted.

These fixtures give a reviewer a concrete path from an aggregate number to the cases outside it. They also keep several absences distinct: a question not included in the latest run, a skipped question, an execution error and a refused answer. None should become a favorable result merely because its numerical fields are null.

Read access and editing were separate contracts

The gateway retained distinct permissions for reading, running and editing evaluation data. The benchmark editor was restricted to the super-administrator role. A reviewer could inspect results without seeing editing controls. Client validation matched the backend's accepted inputs, including blocking saves against a deleted document. Hiding a button was only one layer. The frontend gateway still had to enforce the operation's permission before forwarding it.

What the verification record supports

The implementation merge reports package tests, type checking, lint and build checks, plus browser verification against a local development backend. A follow-up addressed focus return and translation issues. Those checks concern integration behavior and interface states.

They do not establish model accuracy, benchmark representativeness or treatment safety. A small evaluation set remains bounded by its questions and source material. A translated label checked by another machine is not a native-speaker review.

Our practical review path begins beside the percentage: identify the run, inspect excluded counts, then open the result that changed the interpretation. The dashboard earns its place when that path remains available even for failure and refusal states.

FAQ

Last updated: October 22, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 14

• How long have you been in business?

  Copy link Copies a direct link to this answer to your clipboard.

  Pharos Production has been in business since 2013, with over 13 years of experience in custom software development. During this time, we have delivered over 110 applications for 200+ clients across 28 industries, including FinTech, healthcare, crypto and e-commerce. We are rated 5/5 on Clutch based on 107 verified reviews (2026).

• What services do you provide?

  Copy link Copies a direct link to this answer to your clipboard.

  Pharos Production provides six core service categories: AI Development (LLM applications, AI agents, machine learning and computer vision), Blockchain and Web3 (smart contracts, DeFi, tokenization on Ethereum, Solana, TON and other chains), FinTech Development (payment platforms, digital banking, KYC and AML integration), Software Development (mobile apps, web platforms, database design, UI/UX), Security and QA (code audits, penetration testing, smart contract audits, manual and automated testing) and Consulting (architecture design, MVP validation, startup consulting).

• Where is Pharos Production located?

  Copy link Copies a direct link to this answer to your clipboard.

  Pharos Production is headquartered in Las Vegas, Nevada, USA (5348 Vegas Dr, Las Vegas, NV 89108), with an engineering office in Kyiv, Ukraine (44-B Eugene Konovalets Str. Suite 201, Kyiv 01133). We work with clients worldwide and provide remote collaboration across all time zones. Visit our contact page for directions and scheduling options.

• How big is your team?

  Copy link Copies a direct link to this answer to your clipboard.

  Pharos Production has a team of 90+ engineers, including software developers, blockchain specialists, QA engineers, DevOps experts, UI/UX designers, project managers and solution architects. Our founder, Dr. Dmytro Nasyrov, holds a PhD in Artificial Intelligence and leads the technical direction of all projects.

• What types of customers do you serve?

  Copy link Copies a direct link to this answer to your clipboard.

  We serve a wide range of clients, from startups and product companies to mid-sized enterprises and large institutions. Our clients include crypto exchanges, FinTech providers (like Pleenk), healthcare organizations, sportsbook operators (like Pro Gambling), e-commerce platforms and SaaS companies. Pharos Production has worked with 200+ clients across 28 industries since 2013, adapting engagement models to match each client's stage, whether it is MVP validation for a startup or enterprise-scale development for an established business.

• How is a custom software development company different from an agency?

  Copy link Copies a direct link to this answer to your clipboard.

  A custom software development company like Pharos Production assigns one dedicated engineering team that owns your product across multiple release cycles, instead of handing it off once a contract ends. Agencies more often rotate staff between clients and optimize for fast delivery over long-term product ownership.

  Pharos Production keeps the same team on your codebase through 2-week sprints, so there is no re-onboarding cost each time you request a new feature.

• How much does custom software development cost?

  Copy link Copies a direct link to this answer to your clipboard.

  Custom software development costs vary based on project scope and complexity. At Pharos Production, typical project ranges are: MVP development ($10,000-$25,000), suitable for startups validating a product idea; full-fledged production ($25,000-$50,000), for established businesses scaling a proven concept; and full-cycle development ($50,000-$80,000+), for complex enterprise-grade systems. These ranges include architecture design, development, QA testing and deployment. Hourly rates range from $50 to $99 depending on role and seniority. Final pricing depends on technology stack, number of integrations and engagement model (staff augmentation, dedicated team or project outsourcing).

• How long does it take to develop a custom software application?

  Copy link Copies a direct link to this answer to your clipboard.

  Development timelines depend on scope and complexity. At Pharos Production, a typical MVP takes 2-4 months, a production-ready application takes 4-8 months and a complex enterprise system can take 8-12+ months. We use an agile methodology with 2-week sprints, delivering working increments after each sprint. Every sprint includes a retrospective, progress report and planning session for the next iteration. This approach ensures transparency and allows businesses to launch faster by prioritizing high-impact features first. Get a timeline estimate for your project.

• What industries does Pharos Production serve?

  Copy link Copies a direct link to this answer to your clipboard.

  Pharos Production serves 28 industries: FinTech, MiCA Compliance, Banking, Insurance, Crypto, Healthcare, Fitness, E-Commerce, Food & Restaurant, On-Demand, Manufacturing, Automotive, Energy, Oil & Gas, Supply Chain, Construction, Real Estate, Gaming, Streaming, Media, Telecom, Education, Aviation, Travel, Logistics, Marketing, Agriculture and Recommender Systems. Our deepest expertise is in FinTech, blockchain and healthcare, where we have delivered compliance-ready platforms (HIPAA, PCI DSS, GDPR) and high-load systems handling thousands of concurrent users. For the latest industry insights, read our guides on FinTech trends in 2026 and the Web3 technology stack.

• Why hire a software development company instead of building in-house?

  Copy link Copies a direct link to this answer to your clipboard.

  Hiring a software development company offers faster time-to-market, lower upfront costs and access to specialized expertise without long-term employment commitments. According to Deloitte's 2024 Global Outsourcing Survey, 57% of companies outsource software development to access skills they cannot hire internally.

  Factor	In-house team	Software development company
  Time to assemble	3-6 months (recruiting + onboarding)	1-2 weeks
  Upfront cost	High (salaries, benefits, equipment)	Lower (project-based pricing)
  Specialized expertise	Limited to who you can hire locally	Access to 90+ engineers across blockchain, AI, FinTech
  Scalability	Slow (each new hire takes months)	Fast (scale up or down per sprint)
  Long-term commitment	Full-time employment contracts	Flexible engagement models
  Risk	High if key engineers leave	Company ensures continuity and knowledge transfer

  For businesses that need blockchain, AI or high-load architecture expertise, outsourcing to a specialized firm like Pharos Production reduces risk and accelerates delivery.

• What projects does Pharos Production not take on?

  Copy link Copies a direct link to this answer to your clipboard.

  Pharos Production focuses on mid-to-large custom software projects with budgets starting at $10,000. We do not take on template-based websites, WordPress theme customization or short-term contracts under one month. We also do not provide non-technical staffing (marketing, sales or design-only roles). Our strongest fit is blockchain, FinTech and healthcare projects where security, compliance and high-load architecture are critical. For smaller projects or MVPs under $10,000, we recommend exploring freelance platforms or no-code tools as a more cost-effective starting point.

• Why does Pharos Production use agile methodology?

  Copy link Copies a direct link to this answer to your clipboard.

  We use agile with 2-week sprints because it reduces the risk of building features that miss the mark. Each sprint ends with a working demo, a retrospective and a plan for the next iteration.

  This means clients see progress every 14 days and can adjust priorities based on real results, not assumptions. We chose this approach after years of experience showing that rigid, fixed-scope contracts lead to scope creep, missed deadlines and products that do not match market needs by launch day.

• When should you NOT hire a custom software development company?

  Copy link Copies a direct link to this answer to your clipboard.

  Custom development is not the right choice in every situation. You should not hire a custom software company if: your problem is fully solved by an existing SaaS product (e.g. Shopify for e-commerce, Salesforce for CRM); your budget is under $10,000 and timeline is under 4 weeks; you need a simple landing page or marketing website (WordPress or Webflow is faster and cheaper); or you are still validating the idea and have not spoken to potential users yet.

  In these cases, off-the-shelf tools or no-code platforms offer better ROI. Custom development makes sense when you need unique workflows, regulatory compliance, high-load architecture or competitive differentiation that packaged software cannot provide.

• What kind of projects has Pharos Production delivered?

  Copy link Copies a direct link to this answer to your clipboard.

  Here are three anonymized examples from our recent delivery history:

  FinTech startup - payment platform (MVP)
  Scope: mobile app + backend API with bank-grade encryption. Team: 4 engineers, 1 QA. Timeline: 10 weeks. Budget: $38,000. Result: launched on schedule, processed $2M+ in transactions within the first quarter.

  Healthcare provider - patient portal (Full product)
  Scope: HIPAA-aligned web platform with EHR integration, appointment scheduling and telemedicine. Team: 6 engineers, 1 DevOps, 2 QA. Timeline: 6 months. Budget: $120,000. Result: 15,000+ active patients, zero compliance violations in two annual audits.

  Crypto exchange - trading engine (Complex)
  Scope: high-load matching engine handling 50,000+ orders per second, multi-chain wallet infrastructure on Ethereum and Solana. Team: 8 engineers, 2 QA, 1 security auditor. Timeline: 11 months. Budget: $340,000. Result: 99.97% uptime, passed three independent security audits.

  See more projects: NoMoreBets, Pulse, Sagas, Gambit Stream and Pleenk. For the full portfolio, visit our case studies. Learn more about the technology behind these projects in our guide to stablecoins and crypto infrastructure.

Stas Rysin is the Lead Frontend Developer at Pharos Production. His work covers the design system, reader interfaces and administration workflows of a professional learning platform for aesthetic medicine.