Clink & Afterwork is two products that grew out of one project. Afterwork is a social network where students and junior professionals find their way into co-driven work. Clink is the dashboard for organising those co-driven projects, and it was never planned as a product at all.
CNPT started out doing client work. After a stretch of building things for other people, we wanted something under our own name, so we set out to develop CNPT’s first service of its own.
That service was a mentorship program. Working out how to bring students and junior professionals into work they would drive together is where Afterwork was conceived: a social network for getting into that field.
One of the parts the program needed was a dashboard app, a sub-component for organising the projects people would run together. Building it is where the project turned. Read against the market as it stands, and from where anyone managing a project sits, it was not just a screen our program needed. It was a tool on its own.
So we built it first as an internal workflow app, for our own use, and that dashboard became Clink. From there the strategy was to let it stand without the program around it, and it has been expanded into a project in its own right, alongside Afterwork rather than inside it.
Meet the team
Three co-owners. I lead UX design and the full stack, Brandon leads branding and graphic design, and Kenny leads design audit and management. Holding both the design and the code means the product decision and its implementation have to agree in one place, which is most of what the technical manager role comes down to.
Problem Definition
Thousands of sticky notes?
Every team has its own culture, its own way of talking and its own principles. The tools it works in know none of that, and its context ends up spread across all of them.
We met this while building the mentorship program. The work passing between a mentor and a mentee, and the decisions about running the program, sat in different places, and pulling them back together became a job of its own. That is the problem the dashboard was first meant to solve.
The information is out there somewhere. But if you can’t reach it when you need it, it might as well not exist.
That line became the brief. The question was not where to store things or how to search them, but how far a piece of context sits from the moment it is needed.
What a small team keeps losing
The reasoningThe file survives and the argument that produced it does not, so every revisit starts by reopening a decision that was already made.
The threadA comment stays in the tool it was typed into. Move the file and the conversation about it is left behind.
The cultureHow a team talks and what it agrees on rarely has anywhere to live, so it stays in people’s heads.
Discovery
Why an internal tool was worth expanding
Turning an internal tool into a product is a strategic call, not a design one. Two things made the case.
The first was market value. Read against the tools teams already use, a workspace shaped around how a small team actually works together still looked worth making.
The second came from project management. A small team rarely has someone whose whole job is coordinating it, so the coordinating has to live in the workspace itself. The dashboard was already doing that inside the mentorship program, which is what made it worth lifting out.
The strategy that followed was to expand it independently: keep it as our internal workflow tool, and grow it from there into something other teams can pick up.
What the shift changed
From sub-component to productThe dashboard stopped being scoped by the mentorship program and needed a direction of its own.
From our habits to the interfaceConventions we carried in our heads had to become things the interface states, because another team arrives without our context.
Prototyping
One surface, many kinds of block
Clink is an infinite canvas where a block can be a document, a code snippet, a poll, an availability grid, a reference card or a conversation, all on the same surface at once.
The idea underneath is that keeping “where you think” apart from “where you keep things” is what breaks the thread. So the canvas holds both. A proposal can sit next to the critique that shaped it and the grid that decided when it ships, and where they sit relative to each other says something a folder cannot.
I built it end to end, and that changed how the design decisions got made. When the person drawing an interaction is also the one implementing it, an expensive idea shows itself in an afternoon instead of a sprint, and a cheap one that looks unremarkable in a mockup gets a fair try because trying it costs almost nothing.
Walkthrough
From an empty canvas to a team working on it: blocks, comment threads, document review and the team’s shared state.
What is built so far
Canvas and blocksAn infinite surface with typed blocks, column layout and inline formatting, so a page and a whiteboard stop being different places.
Comments in placeThreads attach to what they are about and travel with it, which keeps the reasoning next to the work.
Document reviewProposals open on the canvas with comments page by page, so review happens where the project already lives.
Team stateAvailability, progress and ownership are blocks like anything else, which is how a three-person team gets project management without a project manager.
Conclusion
Clink & Afterwork is a work in process, incubating through 2026 and 2027.
The lesson I would carry forward is about where products come from. We did not set out to make this one. It came out of building something else carefully enough to notice what we kept needing, and the sub-component turned out to be the part with a future of its own.
The open question is the one every internal tool meets on the way out. Conventions that are obvious to the people who made them have to become obvious to a team that was not in the room, and that is what incubation is for.
