visitor@elmisi.com:~$ cat collab --lang="it"
collab.md

Lavorare insieme

Sono un freelance e scelgo di lavorare solo su progetti che mi accendono. Questa pagina è un filtro: serve a capire prima di scrivermi se ha senso parlarne.

Quello che non prendo

  • Progetti il cui vero scopo è vendere. Se l'obiettivo è il funnel, non la cosa venduta, non sono la persona giusta.
  • "Clona il servizio X." Se l'unica specifica è il confronto con un prodotto esistente, potete tranquillamente usare un coding agent e farlo da voi, sentiamoci se poi vi viene un'idea innovativa o volete far crescere il progetto (validato).
  • "Aggiungiamoci AI" senza un problema reale sotto. Aggiungere AI non è un caso d'uso.
  • Gerarchia e burocrazie. Se ogni scelta deve essere rinegoziata attraverso tre layer di stakeholder, il lavoro si arena e io perdo interesse.
  • Body rental puro / staff augmentation. Non sono una "testa fatturabile" — voglio sapere cosa stiamo costruendo e perché.
  • "Andiamo veloci, sistemiamo dopo." Oltre un certo punto, il dopo non arriva mai, il debito tecnico solo se è un "investimento" sensato.

Quello che invece prendo volentieri

  • Problemi veri, non concetti. Qualcosa di concreto che a qualcuno serve davvero — non "potrebbe essere utile a gente come X".
  • Validazione prima delle feature. Si mette davanti a utenti reali il prima possibile. Se nessuno lo vuole, non aggiungiamo schermate — ci fermiamo e ripensiamo. La validazione non è una fase, è il senso del lavoro.
  • Cose che vanno in produzione. Conta quello che gira davvero, non quello che si demo-a. Output concreto, sempre.
  • Founder che si sporcano le mani. Se la persona di cui è il progetto non c'è nelle call, nelle decisioni, nei test — il progetto deriva e muore. Il commitment dalla tua parte non è negoziabile.

Come si lavora

Dipende da cosa ti serve e da com'è messo il progetto. Modi tipici in cui finisco a collaborare:

  • Scrivo codice insieme a te (o per te, se nessun altro lo sta scrivendo). Decisioni e implementazione su di me.
  • Tu o il tuo team scrivete, io faccio review, pair, architecture. Per il tempo che vi serve e se lo trovate utile.
  • Strategia e messa a terra. Ti aiuto a costruire una strategia e fare in modo che il tuo team porti a casa il risultato.
  • Audit one-shot. Guardo quello che hai, ti scrivo un piano, esco. A volte si continua, a volte no. Entrambe vanno bene.

Quale (o quali) abbia senso lo capiamo dopo aver parlato una volta.

Operativo: remote-first, disponibile a viaggi per kickoff o momenti critici. Time-zone Europa. Italiano o inglese. A progetto di default; a ore va bene lo stesso.

Come si parte

Se pensi che posso portare valore al tuo progetto, mandami una mail a elmisi@protonmail.com. In due-tre paragrafi raccontami:

  1. Cosa stai cercando di costruire. Concreto: il problema, chi avrà il problema, perché adesso.
  2. Dove sei adesso. Hai un prototipo? Un'idea? Un team? Cosa hai già provato.
  3. Perché ci tieni. Non un pitch — un motivo personale di perché vale la pena farlo.

Sono un po' diretto, ma evitiamo tutti di perdere tempo.

Working together

I'm a freelancer and I pick the projects I work on. This page is a filter — it helps you decide whether it's worth reaching out before you do.

What I won't take on

  • Projects whose primary purpose is selling. If the goal is the funnel, not the thing being sold, I'm the wrong person.
  • "Clone service X." If the only spec is the comparison to an existing product, you can just use a coding agent and do it yourselves — talk to me later if an original idea comes out of it or you want to grow the project (once validated).
  • "Let's add AI" without a real problem underneath. Adding AI isn't a use case.
  • Hierarchy and red tape. If every decision has to be renegotiated through three layers of stakeholders, the work stalls and I lose interest.
  • Pure body rental / staff augmentation. I'm not a billable head — I want to know what we're building and why.
  • "Let's move fast, we'll fix it later." Past a certain point, later never comes — tech debt is fine only when it's a sensible "investment."

What I'm glad to take on

  • Real problems, not concepts. Something concrete that someone actually needs — not "it could be useful for people like X."
  • Validation before features. We put it in front of real users as soon as possible. If nobody wants it, we don't add screens — we stop and rethink. Validation isn't a phase; it's the whole point.
  • Things that ship. What matters is what actually runs in production, not what gets demoed. Concrete output, always.
  • Founders who get their hands dirty. If the person whose project this is isn't in the calls, the decisions, the tests — the project drifts and dies. Commitment on your side isn't negotiable.

How we'd work together

Depends on what you need and the shape of the project. A few patterns I usually end up in:

  • I write code alongside you (or for you, if nobody else is writing it). Decisions and implementation on me.
  • You or your team writes, I review, pair, architect. For as long as you find it useful.
  • Strategy and execution. I help you build a strategy and make sure your team carries it to the finish line.
  • One-shot audit. I look at what you have, write you a plan, leave. Sometimes we continue, sometimes not — both are fine.

Which one (or ones) make sense, we figure out after talking once.

Practical: remote-first, available to travel for kickoffs or critical moments. Europe timezone. Italian or English. Project-based by default; hourly works too.

How to start

If you think I can add value to your project, send me an email at elmisi@protonmail.com. In two or three paragraphs, tell me:

  1. What you're trying to build. Concrete: the problem, who has the problem, why now.
  2. Where you are now. Do you have a prototype? An idea? A team? What have you already tried.
  3. Why you care. Not a pitch — a personal reason why it's worth doing.

I'm a bit blunt, but it saves everyone time.