The official reference for our brand identity — visual language, tone of voice, and design system. Last updated April 2026.
01 — Brand Identity
Who we are, what we stand for, and how we position ourselves in the market.
Company overview
Sacks Software Labs is a UK-based software development studio founded on clarity, quality, and delivery. We design, build, and maintain web applications, APIs, and internal tools for startups and growing companies — from MVP to production.
We are a small, self-funded independent operation. Our low overheads allow us to charge roughly half the typical UK agency rate while delivering the same quality. There is no account-manager layer: clients deal directly with the person building their software.
Mission
To give founders and growing businesses access to high-quality, maintainable software — with transparent pricing, no lock-in, and direct communication.
Taglines
Primary
"Custom software. Clear process. No lock-in."
Hero tag
"Software that works."
Footer
"Custom software and web development for startups and growing businesses. UK-based, transparent, no lock-in."
Brand promise — six pillars
🔑
You own everything
Clients own 100% of their code, data, and infrastructure from day one. No exit fees, no hostage situations.
💬
Transparent pricing
Itemised quotes, fixed-price milestones, and honest timelines. No surprise invoices.
🛠️
Modern stack
Maintainable, documented code on well-supported frameworks. No vendor lock-in by design.
📡
Direct communication
No account manager. Clients talk directly to the developer. Faster decisions, fewer misunderstandings.
🔄
Iterative delivery
Ship early, ship often. Real working software at each milestone rather than a big-bang launch.
🤝
Flexible engagement
Project-based or ongoing retainer. Clean handovers if the client's team takes over.
Positioning
We sit between a solo freelancer (limited capacity, often no process) and a full-service agency (high overheads, account layers, lock-in). We offer agency-quality output at freelancer-level rates, with the communication style of a valued colleague.
Target audience
Early-stage founders who need an MVP built fast and correctly
Small-to-medium businesses wanting a custom internal tool or portal
Technical co-founders who need extra development capacity
Businesses that have outgrown their existing off-the-shelf software
02 — Logo
The logo is the single most important brand asset. Use it consistently and according to these rules.
Primary logo
The primary logo is the animated video logo (assets/logo-video.mp4). Use the static fallback (assets/logo.png) wherever video cannot be displayed — emails, documents, print, image embeds.
On dark
On light
Clear space
Maintain a minimum clear space equal to the height of the "S" in the logo on all four sides. No other elements — text, images, or UI chrome — should enter this zone.
Minimum sizes
Digital (header): 210 × 52px (current implementation)
Digital (mobile): minimum 120px wide
Print: minimum 30mm wide
Favicon / app icon: use assets/logo.png cropped to square at 32 × 32px or 512 × 512px
Logo files
File
Use
assets/logo-video.mp4
Primary animated logo — site header
assets/logo.png
Static fallback — footer, emails, documents, print, OG image
assets/logo.png
Favicon / browser tab icon
Logo do's & don'ts
✓ Do
Use the animated video logo in the site header
Use the static PNG in the footer, emails, and documents
Maintain the required clear space on all sides
Use the logo at the recommended minimum sizes
Always include "Sacks Software Labs" in the alt text
Place the logo on a dark (#0F172A) or white (#FFFFFF) background
✗ Don't
Stretch, skew, or rotate the logo
Change the logo's colours or apply filters
Place the logo on a busy photographic background
Add drop shadows, outlines, or other effects
Use the logo smaller than the minimum sizes
Crop the logo or display it with elements overlapping the clear space
03 — Colours
Our palette is anchored by electric blue and lime green — bold, technical, and energetic. All tokens are CSS custom properties defined in style.css.
Brand colours
Brand Blue#00A9E0--brand-blue
Blue Light#33BFEA--brand-blue-light
Blue Dark#0087B3--brand-blue-dark
Brand Green#93D900--brand-green
Green Light#A8E333--brand-green-light
Green Dark#76AD00--brand-green-dark
Signature Gradient135° Blue → Greenlinear-gradient(135deg, #00A9E0, #93D900)
Neutral scale
Gray 50#F8FAFC--gray-50
Gray 100#F1F5F9--gray-100
Gray 200#E2E8F0--gray-200
Gray 300#CBD5E1--gray-300
Gray 400#94A3B8--gray-400
Gray 500#64748B--gray-500
Gray 600#475569--gray-600
Gray 700#334155--gray-700
Gray 800#1E293B--gray-800
Gray 900#0F172A--gray-900
Gray 950#020617--gray-950
Semantic tokens
Always use semantic tokens in code — never hardcode raw hex values. Semantic tokens swap automatically between light and dark mode.
Token
Light
Dark
Use for
--color-text
#0F172A
#F1F5F9
Primary text, headings
--color-text-secondary
#475569
#94A3B8
Body copy, descriptions
--color-text-muted
#94A3B8
#64748B
Labels, captions, placeholders
--color-bg
#FFFFFF
#020617
Page background
--color-bg-alt
#F8FAFC
#0F172A
Card backgrounds, alternating rows
--color-border
#E2E8F0
#334155
Borders, dividers, table lines
--color-accent
#00A9E0
#00A9E0
Links, interactive elements, CTA highlights
Accessibility
All foreground/background colour combinations that carry text must meet WCAG 2.1 AA minimum contrast ratios: 4.5:1 for normal text, 3:1 for large text (18px+ bold or 24px+ regular). Our dark-mode default text (#F1F5F9 on #020617) achieves approximately 16:1. Light-mode default (#0F172A on #FFFFFF) achieves approximately 19:1.
Do not use Brand Green (#93D900) as body text on a white background — the contrast ratio (~3.5:1) is insufficient for normal-weight text. Use it for large display text, icons, or decorative elements only.
#F1F5F9 on #020617 — ~16:1PASS AA
#0F172A on #FFFFFF — ~19:1PASS AA
#93D900 on #FFFFFF — ~3.5:1body text FAIL
#00A9E0 on #020617 — ~5.4:1PASS AA
Colour usage rules
✓ Do
Use Brand Blue as the primary interactive colour (links, buttons, focus rings)
Use Brand Green as success states, checkmarks, and positive highlights
Use the signature gradient on section underlines, dividers, and decorative borders
Use semantic tokens in all code — never raw hex values
Test colour combinations for WCAG AA compliance before shipping
✗ Don't
Use Brand Green for body-size text on white or light backgrounds
Introduce new colours without updating the design system
Apply the signature gradient to large solid background areas
Use both Brand Blue and Brand Green at equal visual weight in the same component
Hardcode hex values in CSS — always use CSS custom properties
04 — Typography
Two typefaces — one for reading, one for code. Use them consistently to reinforce the technical-but-clear brand feel.
Typefaces
DM Sans — Display & body
Design. Build. Ship.
Regular 400Medium 500SemiBold 600Bold 700
We design, build, and maintain web apps, APIs, and internal tools for startups and growing companies. From MVP to production — one team, clear communication, no lock-in.
JetBrains Mono — Code & labels
const build = () => ship();
Regular 400Medium 500
// used for: pill labels, code blocks, version numbers, currency amounts, data values
Base font size: 16px — never set below this on body
✓ Do
Use negative letter-spacing (-0.02em) on headings
Cap line lengths at 60–65ch for readability
Use JetBrains Mono for all code, data values, and version numbers
Maintain the fluid type scale — use clamp tokens for headings
Use italic DM Sans sparingly, for quotes or emphasis only
✗ Don't
Mix typefaces beyond DM Sans and JetBrains Mono
Use font-weight below 400 (no thin/light weights loaded)
Apply letter-spacing to body paragraph text
Set headings in all-caps (use uppercase labels sparingly for UI elements only)
Write body paragraphs wider than 65ch without justification
05 — Voice & Tone
Our voice is consistent across every touchpoint. The tone adjusts slightly to context — a pricing page is more precise, a 404 page can be wry — but the underlying personality never changes.
Brand personality
🧠
Direct & plain-spoken
We say what we mean. No buzzwords, no padding. If a simpler word works, use it.
🪟
Honest & transparent
We acknowledge our size, our pricing rationale, and our limitations. We don't oversell.
🤝
Client-first
The client's goals come first. We frame copy around their outcomes, not our services.
🔧
Technically confident
We use accurate technical language — REST, GraphQL, MVP — but always with plain-language context.
🇬🇧
Distinctly British
British English spellings throughout. Prices in £. Dates in DD-MM-YYYY. UK GDPR references.
😌
Low pressure
No FOMO tactics, no artificial urgency. "No commitment, no pressure" is a genuine stance.
Voice do's & don'ts
✓ Write like this
"We build software you can own and maintain long-term."
"No lock-in. You own your code and data from day one."
"Typically within 1–2 business days."
"Let's talk about what you need."
"We'll get back to you with next steps — no obligation."
"Hourly rate: £25–£40/hr depending on complexity."
✗ Not like this
"Industry-leading synergistic web solutions."
"Limited spots available — act now!"
"We leverage cutting-edge paradigms to disrupt the market."
"Click here to get started on your digital transformation journey."
"Best in class. World class. Award-winning."
Preferred terminology
Use this
Not this
Reason
web application
web app solution / digital product
Specific and accurate
you own your code
full source code ownership transfer
Plain language
no lock-in
vendor-agnostic ecosystem
Direct
fixed-price milestone
fixed-cost deliverable package
Standard contract language
we
our team / our experts
More direct, less corporate
get in touch
reach out / connect with us
British English, less American-startup
startups and growing businesses
SMEs / SMBs
Plain language; SME/SMB can be unclear
quote
proposal / estimate
Consistent across all pages
colour, behaviour, licence
color, behavior, license
British English throughout
£
GBP / USD / $
UK-based, sterling only
Tone by context
Context
Tone
Notes
Homepage hero
Confident, punchy
Short sentences, bold claims grounded in specifics
Pricing page
Frank, informative
Give real ranges; explain the rationale honestly
Contact form
Friendly, low-pressure
Reassure: no commitment, no pressure, quick response
Error / 404 pages
Wry, helpful
A touch of humour is acceptable; always give a clear next action
Legal / policy pages
Clear, neutral
Plain English where possible; no humour; accurate and complete
Client portal / admin
Functional, efficient
Labels and messages should be action-oriented and unambiguous
06 — UI Components
Core interactive and layout patterns. All are built with the CSS custom property system and require no external libraries.
Buttons
Primary (.btn.btn-primary): Gradient background 135deg, #00A9E0, #0087B3. White text. Use for the single most important action per screen.
Secondary (.btn.btn-secondary): Outlined with --brand-blue border. Brand Blue text. Use for secondary actions.
Ghost (.btn.btn-ghost): No background, no border. Subtle hover state. Use for tertiary or nav-level actions.
Never use more than one primary button per visible viewport at any given time.
Cards
Example card
Cards use --color-bg-alt background with a 1px --color-border border and --radius-md (8px) border radius. On hover they receive a gradient border glow.
Background: var(--color-bg-alt)
Border: 1px solid var(--color-border)
Border radius: var(--radius-md) — 8px
Hover: gradient border linear-gradient(135deg, #00A9E0, #93D900) with a subtle box-shadow glow
Padding: var(--space-6) (24px) as a standard starting point
Spacing scale (8px grid)
--space-14px
--space-28px
--space-312px
--space-416px
--space-520px
--space-624px
--space-832px
--space-1040px
--space-1248px
--space-1664px
--space-2080px
Border radius
--radius-sm6px
--radius-md8px
--radius-lg12px
--radius-xl16px
--radius-full99px
Focus & accessibility
All interactive elements must have a visible focus ring: outline: 2px solid var(--brand-blue); outline-offset: 2px
Never use outline: none without a custom replacement
Touch targets must be at least 44 × 44px
All form inputs require associated <label> elements
07 — Imagery & Iconography
Photography and iconography support the brand — they should feel clean, purposeful, and technically grounded.
Photography direction
Developer at work
✓ People working with technology Authentic, candid, purposeful
Clean UI on screen
✓ Product/UI screenshots Real interfaces, not mockups
Prefer images with cool or neutral tones that complement the blue/green palette
Dark-background photography (dark desks, dark environments) integrates well with our dark mode
Avoid warm, orange-heavy images — they clash with Brand Blue
Image credit: Unsplash is our approved free-to-use source. Always attribute where required.
Do's & don'ts
✓ Do
Use real product screenshots wherever possible
Choose photography showing genuine work environments
Apply loading="lazy" and explicit width/height to all images
Always include descriptive alt text
Use WebP format where browser support allows
✗ Don't
Use overtly staged stock photography (handshakes, suits pointing at whiteboards)
Apply heavy filters, grain, or aggressive vignettes
Use images with text baked in (inaccessible)
Stretch or squash images — always maintain correct aspect ratio
Use images with explicit watermarks or third-party branding
Iconography
We use inline SVG icons styled with currentColor for full theme (dark/light mode) compatibility. Icon style follows the Feather / Lucide visual language: 2px stroke weight, rounded linecaps and joins, minimal fill.
Size: 18 × 18px standard; 16 × 16px for dense UI; 24 × 24px for display
Colour:currentColor — inherits from parent text colour
Accessibility: Decorative icons use aria-hidden="true"; functional icons (buttons) require an accessible label via aria-label or adjacent visible text
Emoji
Emoji are used sparingly — only in product demo or informal contexts (e.g., the dev-notice popup, pillar cards). They are never used in marketing headlines, navigation, or legal text.
08 — Social & Marketing
Consistent brand presentation across all external channels — from social media posts to email signatures.
Channel guidance
LinkedIn
Primary professional channel. Share project case studies, technology insights, and company updates. Tone: professional but approachable. Post frequency: 1–2× per week.
X / Twitter
Technical community engagement. Share short code snippets, dev commentary, and product updates. Tone: technical, slightly more informal. The Twitter Card meta tag is already configured on all pages.
GitHub
Open source and public project work. READMEs should follow the same voice guidelines — clear, direct, technically accurate. Link back to the main site.
Email
Client communications and enquiry responses. Sign off with name, title, phone, and a link to the site. Response time target: within 1–2 business days.
OG image & social previews
All pages include Open Graph and Twitter Card meta tags. The current OG image is assets/logo.png. When creating custom OG images for campaigns or case studies:
Dimensions: 1200 × 630px
Background: dark (#0F172A) or the signature gradient as an accent border/bar
Typography: DM Sans, bold for the headline
Include the SSL logo in one corner
Keep text minimal — title + URL or short tagline only
Visual consistency rules
✓ Do
Use Brand Blue and Brand Green consistently across all materials
Use DM Sans for all branded typographical elements
Include the URL (sackssoftwarelabs.co.uk) in all external posts
Keep the tone consistent with the voice guidelines above
Credit image sources (Unsplash attribution where required)
✗ Don't
Use different colour palettes or fonts in external materials
Post content that contradicts the "no lock-in / you own your code" promise
Use stock photography of "generic tech" imagery (neon circuits, binary rain)
Make claims about awards, rankings, or accolades we haven't received
Engage in negative commentary about competitors or clients