DEV Community

Michael Lip
Michael Lip

Posted on • Originally published at zovo.one

Business Card Design Principles That Developers Keep Getting Wrong

I went to a tech meetup last year and collected about twenty business cards. Three of them were memorable. The rest were variations on the same theme: a name, a title, an email, a phone number, a LinkedIn URL, a GitHub URL, a personal website URL, and a QR code. All crammed onto a 3.5 by 2 inch card in 8-point type.

The irony is that developers understand the principle that drives good card design. We just know it by a different name. In code, it's the single responsibility principle. On a business card, it's this: the card has one job -- to make the recipient remember you and have a way to reach you. Everything else is clutter.

The anatomy of a card that works

A standard business card is 3.5 x 2 inches (89 x 51 mm). That's 7 square inches of space. A well-designed card uses maybe 40% of that space for content, leaving 60% as whitespace. The whitespace isn't wasted. It's what makes the content readable and the card feel professional.

The essential elements, in order of importance:

  1. Your name. Large enough to read without squinting. 10-14 point minimum depending on the typeface.
  2. What you do. Not your job title -- what you actually do. "Backend Engineer" is more useful than "Senior Associate Developer III."
  3. One contact method. Email is usually the right choice. Maybe a phone number if your context demands it. Not both plus LinkedIn plus GitHub plus Twitter plus your personal blog.
  4. One URL. If you have a personal site that serves as your hub, use that. The recipient can find your GitHub and LinkedIn from there.

That's it. Four elements. If someone wants your LinkedIn, they'll type your name into the search bar. Putting the URL on the card saves them five seconds but costs you design space and visual clarity.

Typography decisions

The most common mistake is using too many typefaces. One typeface is enough. Two is the maximum -- one for your name, one for everything else. Three or more and the card looks like a ransom note.

For a developer-oriented card, sans-serif fonts project the right tone. Inter, Roboto, Source Sans Pro, or Helvetica Neue all work. If you want to stand out slightly, a monospace font for your name (like JetBrains Mono or IBM Plex Mono) creates an immediate association with code without being gimmicky.

Font sizing hierarchy matters more than font choice. Your name should be the largest text on the card. Your title or description should be noticeably smaller. Contact info smallest. The size difference should be obvious at arm's length, which typically means at least a 3-4 point spread between levels.

Name:        14pt, medium weight
Title:       9pt, regular weight
Contact:     8pt, regular weight
Enter fullscreen mode Exit fullscreen mode

Color and contrast

A developer's instinct is often to use dark backgrounds -- the card equivalent of dark mode. This can work well, but print is not screen. On screen, light text on dark backgrounds is comfortable because the display is backlit. On a printed card, dark backgrounds consume more ink, can smudge, and the white text can look washed out if the printing isn't high quality.

If you go dark, use a professional print service, not your office laser printer. And keep the contrast ratio high. Just like web accessibility guidelines, low contrast on print is hard to read.

For a safe, professional look: dark text on a white or very light background. You can add a single accent color -- a colored line, your name in a brand color, or a colored edge. One color accent is sophistication. Multiple colors are a logo design, not a business card.

The bleed zone and safe area

If your design extends to the edge of the card (a "full bleed" design), you need to understand trim tolerances. Print shops cut cards from larger sheets, and the cut can be off by 1-3mm in any direction. Design your background to extend 3mm (0.125 inches) beyond the card edge on all sides. Keep all text and important elements at least 5mm (0.1875 inches) from the edge.

Card size:        3.5 x 2 inches
With bleed:       3.75 x 2.25 inches
Safe area:        3.125 x 1.625 inches (text lives here)
Enter fullscreen mode Exit fullscreen mode

Ignoring the safe area is how you end up with text that's half-cut off on one edge.

Four mistakes developers make

  1. Including a QR code that links to a vCard. QR codes take up a disproportionate amount of card real estate relative to their utility. Most people will never scan it. If you're handing someone a physical card, you're already having a conversation -- they'll remember you by context, not by a machine-readable code.

  2. Listing every technology in your stack. "React / TypeScript / Node.js / PostgreSQL / AWS / Docker / Kubernetes" on a business card reads like a resume keyword dump, not a professional introduction. If someone wants to know your stack, they'll look at your GitHub.

  3. Using your company's card when freelancing on the side. If you're networking for freelance work, have a personal card. Handing out your employer's card and whispering "but I also do freelance" is awkward for everyone.

  4. Printing 500 cards at once. Your email changes. Your title changes. You rebrand. Print 100-200 at a time unless you're very confident nothing will change in the next year.

The back of the card

Most business cards have blank backs. This is an opportunity. Use it for one thing: a short statement of what you build or what problem you solve. Not a list. Not a logo. One sentence.

"I build tools that make developer workflows faster."

That sentence does more work than a list of technologies because it tells the recipient why they should care.

For generating clean, print-ready card designs with proper bleed zones and safe areas, I built a business card maker at zovo.one/free-tools/business-card-maker.

A business card is a tiny design problem, but it's a complete one. It forces you to prioritize information, establish hierarchy, and communicate identity in a constrained space. Solving it well is a surprisingly good exercise in design thinking.


I'm Michael Lip. I build free developer tools at zovo.one. 350+ tools, all private, all free.

Top comments (0)