The problem
The difficult part of Blinkr’s early product work was translating a broad proposition into something specific enough to build. Connecting complementary people and resources sounds clear until it has to become a set of fields, relationships and actions.
A profile could describe employment history, a useful skill, an available asset or a request for help. Treating those as interchangeable would make the information difficult to interpret. The engineering problem began with deciding what each piece needed to mean.
Context and boundaries
I work on product strategy and backend development together. Blinkr is in ongoing development, with newcomers and experienced older professionals as intended initial groups and the Netherlands as an intended first market.
Those choices give the initial build a direction; they do not establish an existing customer base or a validated collaboration model. The application needs to represent what someone brings and what they need before more ambitious discovery or team-formation features can be useful.
AI-assisted discovery, collaborative team formation and municipality partnerships remain future directions. They are outside the capabilities this case study claims as delivered.
Approaches to evaluate
A conventional professional profile offers a familiar starting point, but employment history does not fully explain what a person can contribute now. Free text leaves more room for expression, while making consistent interpretation harder. Structured skills, resources and requests provide clearer distinctions, but ask for more deliberate onboarding.
These are the design alternatives the product raises. There is no published experiment establishing that one onboarding format performs better. The useful criterion for the build is narrower: can the information support an understandable request or possible collaboration?
The modelling decision
The product has been broken into profiles, skills, resources, requests, categories and discovery workflows. Keeping these concepts distinct gives the backend clearer responsibilities than placing every kind of contribution into a general profile description.
A person and a resource are different entities. A request describes something missing, rather than something already available. Categories provide a shared way to organise those descriptions. Those distinctions guide API boundaries as well as the information shown during onboarding.
The outline below explains the relationship at a conceptual level. It is not the private model schema or a claim that a matching algorithm is operational.
Profile
├── skills and experience
├── available resources
└── requests and interests
Discovery workflow
└── possible complementary capabilitiesImplementation in progress
The backend work uses Python, Django, Django REST Framework, PostgreSQL, REST APIs and JWT authentication. Wagtail supports the content functionality.
My contribution covers backend services, data models, API design, guided onboarding, the tailored content system, automated tests and deployment workflows. Product priorities and implementation continue to inform each other as the application develops.
This account describes the areas being built and the reasoning behind their separation. Exact field definitions, API contracts and the discovery implementation are not reproduced here. The Wagtail study examines the content-system work separately.
Challenges and trade-offs
More structured information can make capabilities easier to understand, but a long onboarding process can ask too much before the user sees a reason to continue. Keeping the input useful without making it exhausting is an ongoing product constraint.
There is also a boundary between preparing for future work and implementing it prematurely. Clear concepts can support later development without requiring the initial build to promise automated opportunity discovery or complete team formation.
Current outcome
The broad concept has been translated into defined application areas and ongoing backend and product work. This gives implementation a more concrete vocabulary than the original proposition alone.
The project is still being developed into a working web application. No adoption figures, measured onboarding improvement or commercial results are claimed here. The project overview introduces the product and intended audience without requiring the architectural detail.
Lessons from the work
The first useful boundary is conceptual: distinguish what a person offers, what they have available and what they need. That makes later technical decisions easier to discuss against an actual workflow.
The second is a boundary of scope. A model should leave room for development without making the first build responsible for every possibility in the business idea. Keeping that distinction visible helps me balance product ambition with work that can be specified, implemented and reviewed.