Our Translation Keys Matched. The Header Still Barely Fit
Matching message keys did not establish label fit, so we inspected content-driven breakpoints, phone controls and the actual locale and viewport matrix
Reviewed by Dmytro Nasyrov on October 22, 2026.
Our translation catalogs could have matching keys while the interface still ran out of room. At 1024 pixels, the French Ask header left roughly five pixels of end padding in the recorded check. On a phone, long translated sort labels could truncate inside controls whose touch targets had been enlarged. These were geometry questions. Key completeness established that a message existed. It did not establish that its label fit beside navigation, a profession badge and an avatar, or that a translated filter remained readable at the narrowest supported width.
The header breakpoint followed its content
The desktop Ask header contained five tabs and account controls. For the English arrangement, the design estimated about 860 pixels, with other catalogs needing more. We moved to the application-bar pattern below 1024 pixels rather than treating a familiar device category as a sufficient breakpoint rule. The transition still needed inspection at the breakpoint itself. Testing only a wide desktop and a narrow phone could miss the state where the desktop composition barely fit. The French end-padding finding came from that intermediate-width check.
We retained it as an open case. The recorded implementation did not justify saying that every translated header had comfortable spacing at every width. A breakpoint can prevent page overflow while leaving a cramped composition.
Touch size and label width competed
The phone design required 44-pixel control height and 16-pixel text. At 390 pixels, the available filter controls could be roughly 170 pixels wide. Longer sort values therefore faced a real width limit even though the control satisfied the height requirement.
Reducing text to make one label fit would have changed another requirement. We needed to distinguish a legitimate truncated selection, an unreadable control and a layout that should wrap or rearrange. A catalog parity test could not decide between them.
| Check | Question it answers |
|---|---|
| Catalog key parity | Does each locale define the required message? |
| Language review | Does the translation express the intended meaning? |
| Control geometry | Does that message remain usable in this layout? |
| Breakpoint inspection | What happens where the composition changes? |
Smaller labels still needed names
On phones, pagination used arrow controls instead of the longer Previous and Next labels. The controls retained accessible names. Removing visible words was a layout decision, not permission to remove the operation's identity.
Filter-label punctuation also belonged to the catalog. French spacing should not be reconstructed by appending a colon in a component that assumes English punctuation. A tiny hard-coded character can create a cross-locale defect even when every substantive word is translated.
We separated these decisions from the card layout itself. Cards addressed field placement. Pagination names and punctuation addressed meaning under reduced space. Combining them under a single mobile-pass label would make the remaining failures hard to discuss.
Keep a locale and viewport matrix
The Ask merge reports inspection of every chat screen at 1440 and 390 pixels in English and Ukrainian, plus the 1024-pixel header in all five locales. The tables work added Ukrainian and German checks on selected phone screens. That is a matrix with deliberate samples, not exhaustive coverage. It cannot be summarized as every screen passed all languages. The source also records the narrow French padding and long sort values, which remain relevant when interpreting those checks.
For a follow-up, the smallest useful artifact is a row per inspected locale, screen and width, with the failing label or control identified. A screenshot without that label can be mistaken for a broader approval than the check actually supplied.
The historical inspection matrix
| Surface | Recorded sample | Limit retained |
|---|---|---|
| Chat screens | 1440 and 390 px in English and Ukrainian | Other locale/screen combinations not inferred |
| Ask header | 1024 px across all five locales | French end padding around 5 px remained open |
| Users and Sources tables | 390 px in Ukrainian and German | Selected screens rather than the whole admin application |
| Phone sort controls | Long translated values | Known truncation cases retained |
Rows describe reported checks, not a fresh browser replay or independent language approval. Keeping the open cell beside the inspected sample prevents a misleading all-locales-pass summary.
What the green catalog test actually compared
The saved catalog test recursively flattened nested message objects into dotted key paths, sorted the paths and compared each locale with the default. It also checked that the reference was nonempty. This is a useful structural assertion because a missing leaf cannot hide behind a matching top-level namespace. It deliberately ignores the rendered width and the meaning of the leaf's value.
The essential comparison can be reduced to the following shape. Setup and file loading are omitted. This extract shows the historical test's method rather than a new browser result.
const referenceKeys = loadKeys(DEFAULT_LOCALE)
expect(referenceKeys.length).toBeGreaterThan(0)
for (const locale of LOCALES) {
expect(loadKeys(locale)).toEqual(referenceKeys)
}
Swapping one valid translation for a longer valid translation leaves that key list unchanged. So does retaining the same keys while hard-coding punctuation beside the translated value. The test should remain green in those situations because its job has not been violated. Asking it to detect cramped navigation would require a different input: the rendered composition.
A failed geometry check therefore needed more than a screenshot filename. For the French header, the meaningful record was the exact width, the active desktop composition and the small amount of remaining end space. For a phone select, the meaningful record was the selected translated value inside the constrained control. A page can fit its viewport while a child control clips a label. Measuring only document overflow would miss that second failure.
Checking the seam between compositions
Our design question at 1024 pixels was whether the full header remained a usable arrangement. Below the boundary, a different application bar took over. The narrow and wide endpoints could therefore both look acceptable while the seam remained uncomfortable. This is why the recorded intermediate-width inspection belongs beside the desktop and phone samples rather than being replaced by them.
A follow-up test should preserve the actual translated strings, account controls and profession badge while inspecting that seam. Replacing them with short fixture labels would change the condition that produced the problem. The same principle applies to phone sorting: the selected long label has to survive into the fixture. A menu rendered with only its shortest option cannot disprove the recorded truncation.
What this changed in our review
We stopped letting a green translation test stand in for a rendered-language check. The implementation still needed both: parity caught missing messages cheaply, while browser inspection exposed the dimensions of actual words.
No independent human verification of every translation or measured usability improvement is claimed here. The engineering case is the separation of completeness, meaning and fit, with a recorded example where the first could pass while the last remained unresolved.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 14
No matches
Try a different keyword, change the topic or clear filters
-
How long have you been in business?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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.