title: Work With Me
description: How Tin Marković structures engagements: from first call to clean handover. With financial guarantees.

# Work With Me

I charge a lot. In return, you get someone who treats your business problem as their own. Not a vendor. Not a resource. A partner.

<!-- Inline HTML: guarantee callouts and the llm-block use styled elements that Markdown cannot express -->

<aside class="guarantee">
  <span class="guarantee__marker">// guarantee</span>
  <p>If I ever break the guarantees I've given you — you'll receive your money back, and I'll work pro-bono to hand over the existing progress to someone else of your choosing.</p>
</aside>

-----

## Beginning

Before anything gets built, we need to agree on what we're actually solving. I'll run a requirements call — not to gather tickets, but to find the real goal under the stated goal. What you describe and what you need are often not the same thing. I'll tell you when that's the case.

This phase can end in a research deliverable: full documentation of the problem space, options, tradeoffs, and a recommended path. That deliverable is yours, regardless of whether I build it.

<aside class="guarantee">
  <span class="guarantee__marker">// guarantee</span>
  <p>I will never use AI for communicating with you. I'll never have other interests than your own, without clear disclosure. All designs are purely your property.</p>
</aside>

<div class="llm-block">
  <h3>On LLMs</h3>
  <p>I use modern tools — language models included. I'd be slower and more expensive if I didn't.</p>
  <p>What LLMs don't do: decide what to build, understand your business constraints, know which shortcuts will cost you in a quarter, or take responsibility for shipping something wrong. That's judgment. Judgment is the job.</p>
  <p>"Vibe coding" — committing unreviewed output to your production system because it looked plausible — is how you get a fast v1 and a maintenance crisis. I don't do that. Everything that ships, I've understood, reasoned about, and am prepared to defend.</p>
  <p>If you've inherited a codebase built the other way, I've fixed those too.</p>
</div>

-----

## Middle

While we work, you'll know what I know.

Every week: what was done, what's being done, what comes next. No surprises, no surprises-disguised-as-minor-updates. If something's going sideways, I tell you before it's a fire.

I've managed through COVID-era engineering restructures and multi-team distributed system builds. There is no delivery complication I haven't seen. What I can promise: you will not sit in the dark.

<aside class="guarantee">
  <span class="guarantee__marker">// guarantee</span>
  <p>I am ready to financially guarantee these promises are upheld. Your project will not sit idle, you will be updated on any and all issues, and I'll keep communication channels open and attended.</p>
</aside>

-----

## End

Software doesn't end — but engagements do.

We'll build acceptance criteria together. Automated tests will verify them on your real infrastructure. When the project closes, it closes cleanly: documentation, runbooks, handover. The next team will be able to continue without calling me.

(That said, I'm available if they do.)

<aside class="guarantee">
  <span class="guarantee__marker">// guarantee</span>
  <p>I'll never be the only person with the keys to your project. A handover plan is always going to be available.</p>
</aside>

-----

## After

I build for longevity. I don't fear the handover, and I don't engineer dependence. If you want a retainer arrangement — ongoing technical leadership, team mentoring, or architecture review — we can discuss it. It won't be because you're stuck. It'll be because you want to keep moving.

<aside class="guarantee">
  <span class="guarantee__marker">// guarantee</span>
  <p>I'll be open for future cooperation. I won't leave you "holding the bag" if you need future assistance.</p>
</aside>