Senior backend developer · available from September
One real backend problem. One paid week. A result you can judge.
I’m Jack Gonchik — 15+ years building and running production C#/.NET systems. The usual way to find out whether a senior developer is any good is an interview, a take-home, and a hope. This is the other way: give me one meaningful backend problem and repo access, and after a week you have a concrete result to judge instead of a promise.
€1,000 for the first week. If it’s useful, we continue — around €4,000 a month, remote, through my own EU company. You evaluate me on what I deliver, not on how well I talk about myself. I can sign an NDA before I see anything sensitive.
Best fit: a small team with a real backend or product problem that has become hard to move.
The offer.
Hiring a senior developer is slow, expensive, and hard to reverse. You commit before you have seen the work, and the real test — how someone reasons about your system, not how they perform in an interview — only starts after the contract is signed. This inverts that.
- One paid week — €1,000. You give me one meaningful backend task, repo access, and enough context. I spend the week understanding the part of the system it touches and delivering a concrete result. Not a tiny isolated ticket — a real piece of work where understanding the system is the point.
- If it works, we continue — around €4,000 / month. Remote, through my own EU company, month to month, no lock-in. Senior European backend capacity at a fraction of the cost and commitment of a local hire.
- Low risk by construction. You are not making a hiring decision under uncertainty. You get one meaningful result first, and judge by that. If it is not useful, there is no obligation and nothing to unwind.
A good first task is one where understanding the system matters:
- build or repair one backend workflow, end to end;
- clean up a fragile, change-resistant area and make it safe to touch;
- improve an API, an integration, or an admin flow that has grown awkward;
- fix a business-rule-heavy part where the logic is spread across too many places;
- connect an external service properly — payments, email, a vendor API;
- review a messy module and deliver a concrete, evidenced improvement.
The proof is a product you can open.
Most developer portfolios are screenshots and dead links. Mine is a production system you can use right now. CompanyGraph is a stock-analysis product I designed, built, and run on my own — backend, data pipelines, admin, public site, AI workflows, payments, deployment.
What it is, concretely:
- 14,000+ generated, server-rendered company pages, each composed from financial data, structural signals, and industry benchmarks.
- A structural observation engine that scores every company on more than 200 structural signals, gated to a firing threshold so a page shows the few signals that are actually present, not noise.
- AI-generated research reports built from verified evidence, with a live generation console — and every claim labelled by how strongly it can be asserted, so the model is never allowed to promote a guess into a fact.
- Company-versus-company and company-versus-industry comparison, Stripe subscriptions, a report-credit ledger, magic-link sign-in, and a multilingual public site.
- Built as roughly fourteen small services behind one composition backend. Frontends speak only to the backend; the services reference each other by id only; the contracts between them are typed, so a breaking change is a compile error, not a surprise in production.
- Deployed by push-to-main, each service on its own systemd unit behind nginx, with centralized error capture and a public status board the tests report into.
It is not a toy. It is a system with many moving parts, kept legible enough that one person can hold it. That is the kind of complexity I am comfortable owning — and you can read the live map of it on the architecture page.
How I think, with the receipts attached.
A CV tells you what someone has done. It does not tell you how they reason — and on a real system, the reasoning is the job. So I write mine down. Across about a hundred pages on this site I have stated, in the open, the positions I actually work from. Not slogans: positions with the structure underneath them, each one a link into the full argument.
- A backend is good when the next important change costs less than the last — not when it is elegant, new, or covered in tests.
- Discipline is a claim until it is checked — shown with a live rule-break in my own production code, left in so you can verify it.
- Most friction is not one bad file, but rules that lost their home — why working software gets slower to change without anything obviously breaking.
- AI made code cheap to produce, not cheap to own — the bottleneck moved to deciding where each piece belongs.
- Every piece of data has one owner; everyone else keeps an id and asks — the rule that keeps fourteen services from collapsing back into one.
- The map is not the terrain: memory routes, the code answers — how I keep notes and AI from drifting away from what actually ships.
If you want to know how I would treat your system, these are the commitments I would bring to it — and they are already load-bearing on a system that runs.
Real decisions, not perfect ones.
Code output is the easy part. The harder, more telling part is judgment under constraint: seeing the clean architectural answer, seeing the cheap hack, and choosing the proportional middle — then naming the boundary so the choice doesn’t spread. A few real ones, with the pure option and the cheap one shown next to what I actually did.
Decision 01
Where the active-language list lives
A universal settings service would have been the pure abstraction, but one active-language list didn't justify a new central brain. The list lives where the product is already composed, and the boundary is named so it can't spread.
The full reasoning
Situation
Several subsystems need to populate translated data — stock-service owns stock rows, email-service owns templates, the CMS owns content, the backend composes the product. All of them need one shared answer: which languages are active right now?
The pure architecture
A dedicated product-settings or configuration-authority service that owns language policy — and later feature flags, rollout state, limits. Clean in the abstract: translation work and language policy fully separated, each subsystem just asks what's active.
The cheap version
Let every subsystem keep its own active-language list. Trivial today, but it's the same truth copied into six places — guaranteed to drift the first time a language is added or paused.
What I chose
The product root owns the canonical list: it lives in the backend's SubWebsite table. Subsystems stay deliberately ignorant of it — they can't call the backend, so a local copy would drift — and instead each exposes one idempotent “ensure these languages” capability the backend drives. Translation-service does the translating; it does not own the list.
Why it was proportional
One small language list did not justify a whole new service — another contract, another deployment, another thing that can be down. But duplicating the list would guarantee drift. Putting it where the product is already composed gives one source of truth without any new machinery.
What could become correct later
The honest trigger to revisit: several settings that genuinely cross subsystem boundaries and have to change at runtime, not at deploy — feature flags read by more than one service, rollout percentages, public limits. At that point a small typed settings package earns its place and the language list moves into it; a full settings service only if those values must change with no deploy and be read by services that can't call the backend. Today it is one shared list plus a few backend-local flags — below that line, so the package doesn't exist yet.
The boundary
The backend owns the active-language list as product configuration. Each subsystem still owns how its own translated rows are created. The settings idea has to stay configuration — it must never become a central brain that owns subsystem behavior.
Decision 02
One product, many services, one composition point
One product needs one composition seam. The backend composes the product; the subsystems keep ownership of their own truth.
The full reasoning
Situation
CompanyGraph is one product built from many services — stock-service, the observation engine, the CMS, image, email, translation, logging, the backend, the website, and the admin.
The pure architecture
A more formal service ecosystem: every subsystem exposing fully product-shaped data, independent versioning, published SDKs, the full enterprise ceremony.
The cheap version
Let each frontend call whatever service it needs directly. Fast to wire, but now the UI knows every internal address and authorization is enforced in two places.
What I chose
Frontends talk only to the CompanyGraph backend. The backend is the composition layer — it assembles stock-service, the engine, the CMS, image, and per-user state into one coherent product shape. Subsystems reference each other by id only and never call each other; the contracts are typed SDKs, so drift is a compile error, not a runtime surprise.
Why it was proportional
The user experiences one product, not ten services. The backend is the right and only place to assemble the product-specific shape, while each subsystem keeps ownership of its own truth. No hidden second composition point, no duplicated auth.
What could become correct later
If multiple products ever consume the same services independently, this may need published packages and version-skew handling — more formal contracts than one product needs today.
The boundary
Backend composes, subsystems own. Frontends never call extracted services directly, and subsystems never call each other — only infrastructure, like logging.
Decision 03
Testing where the risk actually lives
Some rules only prove themselves when the real workflow runs. I put the heavier tests where the risk lives in the interaction, not everywhere.
The full reasoning
Situation
CleverShares has rules whose failures only show up over time — student activity, virtual cash, XP, lessons, stock orders, family agreements, and admin actions, all interacting.
The pure architecture
A full end-to-end simulation environment built out for every scenario.
The cheap version
Mock the isolated methods and call it tested — green, but proving only that the code agrees with itself.
What I chose
Integration tests that run through the real service layers against a throwaway Postgres per test (Testcontainers), for the rules where workflow consistency is the risk — including simulating weeks of activity and checking that cash, XP, and orders stay consistent.
Why it was proportional
The risk isn't one method returning a wrong value; it's a real workflow drifting into an inconsistent state after many actions. Only the real path catches that — a mock never would.
What could become correct later
As the product grows these can become named scenario suites, shared domain fixtures, or a more formal behavior-verification layer.
The boundary
Heavier integration tests where the rule interaction matters; not every tiny unit turned into a full integration test.
Decision 04
AI inside boxes, not AI as architect
I don't just use AI to produce code. I build systems where AI can help without becoming the architect.
The full reasoning
Situation
I use AI heavily while building. It becomes dangerous exactly when a system has no clear places for work to land — then it produces entanglement as fast as it produces features.
The pure architecture
A rigid governance system around every AI change — formal workflows, approvals, generated specifications before any edit.
The cheap version
Let AI modify the codebase freely and trust the review afterwards.
What I chose
Keep the system structured into clear boxes — layers, named DTOs, typed clients, written boundaries. AI works inside those boxes; the architecture and the final responsibility stay human-owned.
Why it was proportional
A messy codebase plus AI becomes more mess; a structured codebase plus AI becomes leverage. The structure is what lets AI help without dissolving ownership.
What could become correct later
This could become a stronger AI-assisted protocol — task packets, subsystem entry maps, boundary checks, automated verification before merge.
The boundary
AI assists implementation, exploration, refactoring, and documentation. It does not own architecture, product intent, or final behavior.
Decision 05
Reports show confidence, not certainty
The product should show how strong a claim is, not pretend every sentence carries the same certainty.
The full reasoning
Situation
CompanyGraph's reports must not pretend to know more than the evidence supports. Some claims are computed facts, some are structural readings, some need external sources, and some are simply missing.
The pure architecture
A full research pipeline where every claim is verified, sourced, classified, stored, and re-checked before any report ships.
The cheap version
Ask an LLM to write a polished report from whatever data is around.
What I chose
A pipeline built around staged questions, evidence packets, claim types, and confidence levels — with the uncertainty kept visible. Start thin, but keep the method honest: every claim carries where its backing comes from and how strongly it can be asserted.
Why it was proportional
The product's trust depends on not collapsing facts, interpretations, and unknowns into one confident voice. A thin honest report is worth more than a rich fake one — fluent prose makes a fabrication more dangerous, not less.
What could become correct later
As it matures: more verifiers, real external sources, stored claim records, stage-level inspection.
The boundary
Computed facts stay separate from structural readings. External claims need sources. Missing evidence is a valid output, not a failure to paper over.
There is usually a pure solution. Purity isn’t automatically right — sometimes it builds more machinery than the problem deserves. The senior call is the proportion, and the boundary that keeps it from spreading.
How I work.
I’m looking for practical B2B backend work on real product systems: APIs, workflows, integrations, admin flows, data models, business rules, and fragile areas that need to become easier to change. I work best when there is enough substance in the task to reason about: what the product is trying to do, where the rules live, what data has to be correct, and what has to stay fast.
I do not believe architecture is one-size-fits-all. The right API, data model, cache, or integration depends on what the business needs the system to do. My job is to understand that context and turn it into working software — and to leave every part I touch more legible than I found it, so the understanding ends up in the system instead of only in my head.
Two honest boundaries, because they keep the work serious rather than magical. First: I will not pretend I can understand your business in a week — the early days are mostly me learning what your system is supposed to do, while still delivering one concrete thing as I go. Second: I use AI as a tool, not a replacement for thinking. It increases the supply of code; it does not decide which behaviours are intentional or where a rule belongs. The architecture and the final responsibility stay with me.
The best fit is a company whose system has substance and some friction — an area that works but is fragile, unclear, slow to change, or missing a workflow it needs. That is exactly the kind of work I like, and the kind a one-week task is built to test.
Background.
15+ years in production backend work. For thirteen of them I built and ran ServiceByen.dk on my own — a service marketplace operating across Denmark, where I was the architecture, the backend, the deployment, and the person who got the call when it broke. Before that, backend work at Den Blå Avis / eBay Classifieds inside a Scrum team. Today I am main developer at CleverShares and I build CompanyGraph independently.
The stack: C#, .NET 9, ASP.NET Core, EF Core, PostgreSQL and SQL Server on the backend; React, TypeScript and Next.js on the front; Linux, nginx, systemd and CI/CD in production; xUnit, Moq and Testcontainers for tests. Backend-first, full-stack when the work connects to it.
The conventional version — the years, the roles, the full history — is one click away: my CV.
A simple next step.
Send me one backend problem you would like solved or improved. If it looks like a fit for a one-week task, we agree the scope, an NDA if you need one, access, and a start date. I read every one, and the first reply is mine, not a calendar link.