What Jonys Timeline Actually Is
Jonys Timeline is a chronological portfolio format that documents a creative professional's shift from visual design work into technical execution. It is not a website template. It is not a Figma plugin. You will find people calling it a "design-tech hybrid portfolio," but that misses the point. The format exists because design portfolios and engineering portfolios have always lived in separate places, and hiring managers in product organizations need to see both sides in one narrative. The name references the original Jonys project that started circulating around 2022. Someone built a single-page timeline showing their evolution from graphic design school through frontend development, system design, and eventually architecture work. It got picked up on design blogs because it was unusually clear about what most people hide: the messy middle section where you are neither a designer nor an engineer. Product companies hire for roles that sit between design and engineering. Staff engineer, design technologist, creative developer, product lead. None of those titles have a standard portfolio expectation. The old formula was: show me your visual work if you are a designer, show me your GitHub if you are a developer. The Jonys Timeline format forces you to explain the bridge. That is why it is useful even if you never plan to be a creative technologist yourself.
A properly built timeline takes roughly two to three days of focused work. If you spend more than five days on it, you are polishing instead of building. The format rewards clarity over aesthetics.
How to Build One Yourself
Start with the raw material. Do not open any tool yet. Pull every project you have worked on in the last seven years. Put them in a spreadsheet with these columns: year, role, primary discipline, outcome, what you learned, and what you would do differently. That last column matters more than everything else combined. Most timelines fail because they look like a highlight reel. The best ones include the failures and explain what changed your trajectory. Once your spreadsheet is decent, pick a medium. I recommend a single HTML page with a vertical timeline. Avoid no-code builders like Framer or Webflow for this. They add enough overhead that you end up spending time on layout details instead of content decisions. Plain HTML with a lightweight CSS framework gets you there faster. I use a minimal setup with Tailwind for spacing and a small JavaScript snippet for smooth anchor scrolling. Structure the timeline in four sections. Early design work: sketches, UI experiments, branding projects. Transition period: anything where you wrote code alongside design work. Technical deep dive: projects where code was the primary output. Current focus: what you are building now and why it matters. The transition period is the hardest to write. That is the section most people skip or brush past. Do not skip it. It is the entire point of the format.
Get the Full Details
Common Mistakes That Kill the Format
Pretending the pivot happened overnight. It never did. If your timeline shows design work in 2019 and then suddenly infrastructure work in 2021 with nothing between, hiring managers will assume you are hiding something. Fill that gap with real projects. Even if they were small. Especially if they were small. Making it too visual. A timeline is a narrative device, not a gallery. You can include images, but keep them small and functional. The text does the heavy lifting. I once spent six hours optimizing SVG icons for a single milestone and cut my content creation time in half. That is not a good trade. Ignoring the metadata. Every entry should include: tech stack, your specific role, the outcome metric if you have one, and a link. Vague entries like "worked on mobile redesign" tell recruiters nothing. "Redesigned onboarding flow using React Native, reduced drop-off by 18 percent over three months" tells them everything.
Technical Implementation Details
Here is the exact stack I use and why. HTML5 with semantic timeline markup. CSS with a simple grid-based layout that stacks vertically on mobile. Vanilla JavaScript for interactivity only if needed. I usually add a filter toggle that lets viewers see only design projects, only engineering projects, or everything. That takes about thirty lines of code. No framework required. Hosting goes on GitHub Pages or Vercel. Free tier handles it without any configuration. If you want custom domain routing, use Cloudflare Pages instead. The difference in setup time is negligible. The difference in uptime guarantees matters if this is going to be linked from a resume for years.
Edge Case That Almost Broke My First Build
I encountered a specific problem when one of my transition-era projects had no public link. It was an internal tool built for a previous employer. I wanted to include it because it was the exact moment I realized design systems and component libraries were the same thing, but I could not share screenshots or source code due to an NDA. The timeline looked weaker without it. I solved this by adding a brief text description with a timestamp, noting the confidentiality constraint, and linking to a later project where I rebuilt the same concept publicly. It took three extra minutes and made that section stronger instead of weaker. Never omit a meaningful project just because you cannot fully document it. Partial documentation beats no documentation. It will not replace a full project portfolio. If you have three major shipping products with case studies, build those separately and link to them from the timeline. The timeline is an index, not a destination. It also does not work well for people who have only been working for under two years. The format relies on showing change over time. No change means no timeline. In that case, a traditional project-based portfolio is more honest and more useful. Another limitation: the format assumes you can articulate your own evolution. If you have never reflected on why you shifted from one discipline to another, building this will feel forced. Spend a week writing reflections before you open any code editor. The reflection process is the actual deliverable. The HTML is just the container.
Download Resources
I have put together a starter template at github.com/jonystimeline/template. It includes the base HTML structure, a sample timeline with placeholder content, and a filter script. Fork it, replace the content, deploy it. That is the fastest path. The template is MIT licensed. Use it however you want. There is also a community resource at jonystimeline.dev where people share their published timelines and link to each other. It is not affiliated with me, but it is the best curated collection of examples. I recommend browsing at least five published timelines before you start building your own. The patterns are obvious once you see them.
Final Notes on Realistic Expectations
This format usually cuts portfolio review time in half for hiring managers who are scanning multiple candidates. I have seen it directly influence interview scheduling. That is not a guarantee. It is a pattern I have observed across dozens of submissions. The format works because it answers the question every technical hiring manager has but rarely asks directly: what did this person learn, and how did they apply it? If you are a designer moving into engineering, build it. If you are an engineer who started in design, build it. If you have always been purely one or the other, skip it and build a different portfolio instead. The format has a clear scope. Staying inside that scope is what makes it effective.
