Why I Built My Own Digital Business Card

I recently ordered an NFC business card.

The obvious next step was to point it at one of the digital business card services that already exist. They solve the problem: tap the card, open a profile, show some links, save the contact.

But I already have a website that represents me.

So instead of adding another profile to maintain, I built /card directly into my portfolio.

The result is deliberately small. It has my profile, the things someone is most likely to want after meeting me, a downloadable contact file, and links back into the rest of my work.

What interested me was not building another link-in-bio page. It was making a physical card, a contact file, my portfolio, and my machine-readable identity all point to the same place.

The NFC card is just the entry point

An NFC card is not really the product here.

It stores or opens a URL. Mine can point to:

https://www.jansencadorna.com/card

That means the physical card can stay the same while the page behind it changes.

If I change what I am building, update my resume, replace a project, or change where I want people to contact me, I update my website. I do not need to reprint or reprogram the identity itself around a third-party profile.

That was the first constraint I wanted: the card should resolve to something I own.

I have already spent time making my website machine-readable, connecting my portfolio to the profiles and projects that represent me. Sending an NFC tap somewhere else would create another identity surface when I could make the portfolio itself do the job.

I designed the page around what happens after meeting someone

My normal portfolio is meant to be explored.

A contact card is different.

If I meet someone at an event and they tap my card, I do not expect them to read a long About page while we are standing there. The page needs to answer a much smaller set of questions quickly:

• Who is this?
• What does he do?
• How do I connect with him?
• What is he currently building?
• Can I save his contact details?

So /card is intentionally narrower than the homepage.

It exposes direct actions for my resume, LinkedIn, GitHub, email, portfolio, and booking a call. It also shows the projects I am currently leading instead of trying to reproduce my entire /works archive.

That distinction matters to me. A smaller interface is not a less complete portfolio. It is an interface designed for a different moment.

The useful part is the .vcf

I did not want the page to stop at a list of links.

There is also a /card/contact.vcf route that generates a contact file from the same site configuration I already use elsewhere in the portfolio.

The response contains fields such as my formatted name, structured name, professional title, email, portfolio URL, and LinkedIn URL. It is returned as a vCard download instead of being maintained as a separate static contact file.

vCard is a standard format for representing and exchanging contact information. The specification defines properties for things such as names, email addresses, telephone numbers, URLs, organizations, and other contact data.

That gives the page a useful transition from web profile to actual address book entry.

Instead of:

meet -> tap -> view links -> forget about the page

I can support:

meet -> tap -> view profile -> save contact

The implementation is small, but that final step makes the card materially more useful.

I reused the site's identity instead of duplicating it

One thing I wanted to avoid was hard-coding another copy of my name, title, email, profile image, social URLs, and project information inside the card page.

Most of those values already have canonical sources in the portfolio.

The contact file reads from siteConfig. The page uses the same profile image and identity data. Current projects come from the existing project data. Booking uses the same meeting component already available elsewhere.

Conceptually, I wanted this:

siteConfig + project data
          |
          |-- portfolio
          |-- about page
          |-- structured identity
          |-- digital card
          `-- contact.vcf

rather than five slightly different versions of me scattered through the repository.

That is the same reason I prefer deriving systems from existing data when I can. I used a similar approach when I generated blog covers from article metadata: if the source of truth already exists, I would rather compose from it than create another thing to keep synchronized.

I still made the page indexable

The page exists primarily for people I meet in person, but it is still a public page on my domain.

So I did not treat it as an invisible utility route.

It has its own metadata and a ProfilePage JSON-LD object whose main entity points back to the same Person identity used by the rest of the site. It is also included in the site's discovery surface instead of being an orphan URL that only works when someone physically taps the card.

I like that combination because the page has two jobs without needing two implementations:

For a person: it is a fast way to connect with me.

For a machine: it is another page on my canonical domain that describes the same identity and links into the same graph.

I am not expecting a contact card page to become some SEO growth hack. That is not why it exists. I just do not see a reason for a useful public page to throw away good metadata and structure.

The physical card can now outlive the design

The part I like most is that the physical object is now decoupled from most of the information on it.

My job title can change.

My main project can change.

My resume will change.

The social platform I care about next year might change.

The NFC card can keep opening the same URL.

That is a much better model for me than printing every piece of professional information permanently onto a card or depending on a hosted digital-card profile as the canonical version.

The physical card is just a pointer.

The website remains the source of truth.

I would build it the same way again

If I were doing this again, I would keep the scope almost exactly where it is.

I would not build a contact-management platform. I would not add accounts, analytics dashboards, themes, or a CMS just because digital business card products have those features.

For my use case, I needed one durable URL with a few reliable actions:

1. identify me quickly
2. show what I am currently doing
3. provide the important ways to connect
4. let someone save my contact
5. lead back into the larger portfolio when they want more context

That is enough.

It is a small feature, but it represents something I have been trying to do more consistently with my portfolio: make every public surface reinforce the same identity instead of creating another disconnected profile.

Now when I hand someone a card, I am not sending them to a service that represents me.

I am sending them directly to my own site.