visitor@elmisi.com:~$ cat collab_it.md # english version below
collab_it.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é.
  • Capitolati chiusi e preventivi al buio. Se la specifica è già scritta e cerchi solo chi la esegue al prezzo più basso, non fa per me. La commessa la definiamo insieme.
  • "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:

  • Sviluppo a commessa. Mi porti un problema, definiamo insieme cosa serve, lo costruisco e te lo consegno in produzione. Perimetro e prezzo concordati prima, a tappe corte: si consegna un pezzo, lo si mette davanti agli utenti, si decide il successivo.
  • 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 commessa o a progetto di default; a ore va bene lo stesso. Fatturo sia consulenza sia sviluppo software a commessa.

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.

visitor@elmisi.com:~$ cat collab_en.md
collab_en.md

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.
  • Closed specs and blind quotes. If the spec is already written and you just need someone to execute it at the lowest price, I'm not your person. We define the job together.
  • "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:

  • Build to order. You bring a problem, we define what's needed together, I build it and hand it over running in production. Scope and price agreed upfront, in short steps: ship a piece, put it in front of users, decide the next one.
  • 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. Build-to-order or 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.