Tenía la cuenta de ahorro. Me sabía el saldo de memoria.

⁠

Lo que no sabía era si la moto llegaba en 2027 o en 2031.

Y esa es la parte que importa. El saldo te dice dónde estás. No te dice si vas a llegar.

Guarda esto, que al final del email vuelvo.

Desde hoy los objetivos de ahorro están disponibles para todo el mundo en Whisper Money.

Un presupuesto le pone un techo a lo que gastas.

⁠

Un objetivo le pone un suelo a lo que ahorras.

Se crea en un minuto: le pones nombre, dices a cuánto quieres llegar y eliges una fecha si la tienes.

¿Ya tenías algo apartado antes de empezar? Lo metes y cuenta desde el primer día. Nadie empieza de cero.

A partir de ahí sabes si vas adelantado o atrasado, cuánto te toca meter cada mes para llegar a tiempo, y en qué día terminarías si sigues al ritmo que llevas ahora.

Un detalle que me costó decidir: el dinero que ya tenías suma al total, pero no cuenta para el ritmo.

Si contara, el primer día tendrías un ritmo altísimo y la app te diría que acabas la semana que viene. Bonito, pero mentira.

Ahora, la parte que hace que esto no se te caiga a los tres meses.

Por dentro, un objetivo es una etiqueta. Etiquetas el traspaso que alimenta el bote y el objetivo lo suma.

Fácil. Pero etiquetar a mano todos los meses cansa, y al final lo dejas.

⁠

Por eso puedes dejárselo a una regla automática.

Una regla que diga “todo lo que entre en mi cuenta de ahorro va a este objetivo”. Se aplica también a lo que ya estaba, así que el histórico se cuenta solo.

Lo configuras una vez. El traspaso del mes que viene llega ya contado.

Lo tienes todo explicado aquí, incluido el error clásico de etiquetar los dos lados de una transferencia (no lo hagas, cuenta el dinero dos veces).

Funciona igual para la entrada de un piso, que es el objetivo aburrido que en realidad tiene todo el mundo. Ahí lo que miras no es el porcentaje, es cuánto necesitas al mes para no llegar tarde.

Vuelvo a la moto.

⁠

La Panigale lleva un año en el garaje.

La foto es mía, no de un catálogo.

Tardé dos años en decidirme porque durante dos años no supe cuánto faltaba. Iba a ojo, y a ojo se ahorra peor.

“Añade a los ajustes de notificaciones el aviso nuevo para usuarios sin banco conectado.”

Enter y ya.

Cuando volví había un worktree nuevo, una rama nueva, un agente trabajando por su cuenta y una pull request abierta con el CI en verde y un vídeo de la feature funcionando en el navegador.

Yo no toqué nada en medio.

Y hubo un detalle que no esperaba. En el prompt le dije “email semanal” y no era exactamente eso. El agente que revisa la parte de producto se dio cuenta, corrigió el copy y siguió. Lo vi después, en el vídeo del QA.

Eso es /delegate. Describes la tarea desde el proyecto principal, el agente busca los detalles en el código, monta el worktree en Herdr y lanza ahí otro agente con las instrucciones ya masticadas. El resto lo hace con /ship.

Te lo enseño de principio a fin en el vídeo, con la pull request de verdad y el vídeo del QA.

Las seis skills están publicadas y te dejo el enlace en la descripción del vídeo.

Ya sabes cómo va esto.

Vuelos, el coche de Turo, la compra en Publix, cuatro Starbucks, el parking, Uber, Disney. Todo mezclado con la luz y el súper de casa.

Lo normal es abrir la app, filtrar por fechas y empezar a etiquetar a mano. Cuarenta y tantos toques.

Esa noche estaba en el sofá y probé otra cosa.

Abrí Claude en el móvil y escribí:

“Actualiza todos mis gastos de Whisper Money en la Shared Card para que tengan la etiqueta Miami 26”.

Cinco pasos después me contestó que ya estaba. 45 transacciones. Dos ya tenían la etiqueta, así que se la puso a las 43 que faltaban.

⁠No abrí la app ni una vez.
⁠

A la mañana siguiente, con el café, tiré del hilo.

“Mira todos mis gastos etiquetados con Miami 2026 y hazme un resumen por día y por categoría.”

91 transacciones, del 21 de mayo al 8 de agosto.

Total: 5.728,18 €.
Vuelos: 1.691,34 €.
Alojamiento: 1.159,63 €.
Turo: 671,65 €.
Restaurantes y cafés: 417,54 €.

Tardó menos en calcularlo que yo en decidir si quería saberlo.

Y aquí viene lo que te quería contar.

Esto no es “hemos metido un chatbot en la app”. Es justo al revés.
⁠

Whisper Money ya tiene servidor MCP. Conectas tu cuenta a Claude o a ChatGPT, y tu IA habla directamente con tus finanzas.

28 herramientas: buscar transacciones, gasto por categoría, cashflow, patrimonio neto, presupuestos, etiquetas, categorías y reglas de automatización. Crear, editar y borrar incluidos.

Pero tú decides hasta dónde llega.

Cuando generas el token eliges entre solo lectura o lectura y escritura. Con el de solo lectura la IA analiza todo lo que quieras y no puede cambiar ni una coma.

Y hay una línea que no cruza ni con permisos de escritura: lo que viene del banco no se puede editar ni borrar. Solo etiquetar y categorizar. Lo que trae el banco, lo manda el banco.

La conexión va por OAuth 2.1, la misma que usan los conectores oficiales de Claude y ChatGPT. Autorizas una vez y listo.

Un aviso por experiencia propia: haz la conexión desde el ordenador. En el móvil, la app instalada se pelea con la pantalla de autorización y acabas dando vueltas.

Una vez conectado, ya lo usas desde donde te dé la gana. Yo etiqueté Miami entero tumbado en el sofá.

Está disponible en las cuentas Pro. Ajustes → MCP.

Y para la primera pregunta, mi recomendación: pídele el resumen de en qué te has gastado el dinero este mes.

Luego no digas que no te avisé.

No porque se hubiera roto algo.

Al revés: funcionaba perfecta.

La borré solo para poder grabar el vídeo que te traigo hoy.

Porque esos ajustes los fui metiendo poco a poco, casi sin darme cuenta.

Y resulta que son justo los que hacen que trabajar con agentes en la terminal (Claude Code, Codex, lo que uses) vaya rápido de verdad.

⁠

Casi ninguno viene por defecto.

Y ninguno parece gran cosa hasta que lo ves funcionando.

Como el que hace que la terminal me diga qué está haciendo cada agente, en vez de cómo se llama.

O el atajo que uso más que ningún otro y que todavía no viene de serie en ningún sitio.

En el vídeo los voy desmontando uno a uno: qué cambio, por qué, y qué puedes robarme para tu propio setup.

Dura poco. Y te vas con la configuración entera copiada.

Pero no has terminado.

• Falta el QA.

• Falta revisar el código.

• Falta abrir la PR y escribir una descripción que se entienda.

• Falta esperar a que la CI se ponga verde.

Y si algo peta, vuelta a empezar.

Escribir la feature fue lo rápido. Lo demás es lo que te deja seco.

⁠

Así que hice algo con eso.

Monté una colección de skills para Claude Code y Codex.

La que más uso, de largo, es `/ship`.

Le das una tarea. Y la lleva de principio a fin.

La implementa. Hace QA. Lanza dos reviews de código a la vez. Abre la PR.

Y se queda mirando la CI hasta que está verde.

Yo mientras me tomo un café.

⁠

Pero antes de construir hay que pensar.

Para eso uso `/grilling`.

Coge tu idea y la machaca a preguntas hasta que el plan aguanta solo.

Nada de picar código sobre una idea a medias.

Grabé un vídeo usando las dos en un caso real.

De la idea al merge, sin cortes.

Primero el plan con `/grilling`. Después `/ship` con todo lo demás.

⁠
Si te pasas media vida en la parte aburrida de enviar código, esto es para ti.

🔗 El repo está aquí. Llévate las skills que quieras: victor-falcon/skills

In the same repo.

Each one on its own task.

And me, in the browser, testing what they changed almost in real time.

Sounds like chaos. It wasn’t.

For months I worked with AI the “normal” way: one chat, one task, wait, review, repeat.

Slow.

Until I tried a tool that flipped the whole thing around.

Now I can spin up four, five, six agents in parallel on the same project.

Each one pulling its own thread.

And I jump between them, watching the changes in the browser without setting up anything weird.

The best part isn’t the power. It’s how simple it is.

I recorded the whole thing in a new YouTube video so you can see it actually working.

Pasa casi cada semana. Un peso de aquí, un rand de allá. Gente con bancos en Sudamérica, en África, en sitios que ni sabía que tenían app de banca.

Hace un año esto me habría dado una pereza tremenda.

Ayer añadí la corona sueca en cinco minutos. Y estaba tomándome un café mientras pasaba.

Te cuento cómo.

Abrí una rama nueva, lancé un agente y le escribí una sola frase:

“Añade la moneda al sistema, que funcione tanto en cuentas de usuario como en cuentas bancarias.”

Le pasé un documento de referencia y me fui a por el café.

Cuando volví había una pull request esperándome. Título claro. Descripción clara. Los cuatro archivos justos tocados, con la traducción al español y al francés ya puestas.

Le di a auto-merge.

Cinco minutos después la corona sueca estaba en producción, disponible para todo el mundo.

Y aquí está lo que de verdad quería contarte.

Eso no funciona por magia. Funciona porque antes me senté a documentar el proceso.

Escribí un documento que explica qué archivos hay que tocar para meter una moneda, y otro para conectar un proveedor de datos nuevo.

El agente lee ese documento y sabe exactamente qué hacer. Pero no es solo para el agente.

Es para cualquier persona que quiera colaborar.

Por eso hice Whisper Money open source. Y por eso me pongo a documentar estas cosas.

Un desarrollador que nunca ha visto el proyecto puede abrir la documentación, lanzar Claude Code o Copilot, y en veinte o treinta minutos tener una moneda nueva o una integración funcionando.

Yo no tengo cuenta en todos los bancos del mundo. No puedo probarlos todos.

Pero si tú usas un banco que no está, ahora puedes añadirlo tú mismo.

Ese es el trato.

Grabé un vídeo enseñando el proceso entero, paso a paso, con la corona sueca de ejemplo.

Si quieres ver lo fácil que es, o colaborar con tu moneda o tu banco, empieza por aquí:

I hit go-to-definition.

And then I wait.

One second. Two. On our biggest repo, sometimes five.

You don’t notice it in a small project.

In a monorepo with thousands of files, you feel every one of those seconds.

It turned into muscle memory: hit “find all references,” tab over to Slack, come back when it finished thinking.

That was normal for years. I figured it was just the price of a big codebase.

Then TypeScript 7.0 shipped.

They rewrote the entire compiler in Go. The old one was JavaScript checking your JavaScript, which is about as fast as it sounds.

The build numbers are almost rude:

• VSCode’s typecheck dropped from 125 seconds to about 10.

• Slack cut CI type-checking from 7.5 minutes to 1.25.

• Opening a file full of errors in the editor went from 17 seconds to under 1.3.

⁠
Roughly 8 to 12 times faster across the board.

But I don’t stare at build logs all day. I live inside my editor.

So the number I actually cared about was that editor one.

I wired the native compiler into Neovim, restarted, and dropped my cursor on a symbol in our biggest project.

Go-to-definition.

It landed before my finger left the key.

No spinner, no Slack detour. References that used to take seconds now feel like they were already sitting there.

Here’s exactly what I did. Three steps, about ten minutes.

⁠

Step 1. Install the native compiler.

Global (a fallback for loose files with no project):

  npm i -g typescript@latest      # stable TS 7.0+, ships the `tsc` binary

Per project (recommended, so the LSP uses the repo’s version):

  npm i -D typescript@latest      # lands in node_modules/.bin/tsc

Step 2. Turn it on in Neovim. nvim-lspconfig already ships lsp/tsgo.lua, so you only override the cmd:

  -- Stable TS 7.0 ships as `tsc` in the `typescript` package (LSP via `tsc --lsp`).
  -- lspconfig’s lsp/tsgo.lua still launches `tsgo`, so override just the cmd.
  vim.lsp.config(’tsgo’, {
    cmd = function(dispatchers, config)
      local bin = ‘tsc’

      if (config or {}).root_dir then
        local local_bin = vim.fs.joinpath(config.root_dir, ‘node_modules/.bin’, bin)
        if vim.fn.executable(local_bin) == 1 then bin = local_bin end
      end

      return vim.lsp.rpc.start({ bin, ‘--lsp’, ‘--stdio’ }, dispatchers)
    end,
  })

  vim.lsp.enable ‘tsgo’

root_dir (it finds the root by lockfile, with monorepo and Deno support) and inlay hints already come from lsp/tsgo.lua. Your vim.lsp.config just deep-merges on top.

Step 3. Check it.

tsc --version # → Version 7.0.x

In nvim, on a .ts file: :LspInfo (or :checkhealth vim.lsp), and you’ll see the tsgo client attached.

⁠

A few notes:

• You need Neovim 0.11+. That’s where vim.lsp.config and vim.lsp.enable live.

• It’s not in Mason. The binary comes from npm, not :Mason.

• Want the nightly channel instead? npm i -g @typescript/native-preview (that’s the tsgo binary) and use tsgo as your bin.

That’s the whole thing.

I went from waiting several seconds on our biggest projects, just to jump to a definition or list references, to everything being instant.

The editor finally keeps up with how fast I’m reading the code.

If you write TypeScript in Neovim, give it the ten minutes this week.

Then hold down go-to-definition on your ugliest file and enjoy how quiet it got.

It’s 3 in the morning.

Something breaks in production.

One user, maybe hundreds, walk straight into an error.

I’m asleep.

And still, 15 minutes later, the fix is live. Working.

⁠

Nobody touched a key.

I’ve been messing around with loops for a while now.

In Whisper Money I’ve got an agent that never stops.

Round and round it goes, watching every error Sentry reports.

When it finds one, it does triage.

How many users does it hit? Is it serious?

Based on that, it decides where to start.

Then it gets to work on the fix.

⁠

And here’s the good part.

Before it calls anything done, it reviews itself from three angles at once: the code architecture, the possible bugs and regressions, and the user experience.

If it all checks out, it opens the pull request.

And if the fix is simple and it’s sure, it flips on auto-merge.

The solution ships to production on its own.

Without me lifting a finger.

So far it’s solving all of them.

Zero problems in production. Not one.

⁠

It’s the closest thing to a real employee I’ve ever had. And it’s 100% automatic.

The feeling is strange, I won’t lie to you.

Something blows up, because I just deployed or for whatever reason, and I already know that in 10, 15, 20 minutes it’ll be fixed.

Without opening my laptop.

This isn’t a demo or a LinkedIn video.

It’s running in my production while you read this.

More than 25 products shipped. Just me doing the code, the design, the marketing, all of it.

A couple even sold. A few made decent money. So no, not a flop.

But I never built the one.

The product that pays the bills every month and lets you quit everything else and go all in.

For a long time I blamed the wrong things. The code wasn’t clean enough. The design needed one more pass. Ship it again, better this time.

⁠

That was never it.

I’m a good programmer. I know product. I can design. None of that was holding me back.

What held me back was getting anyone to actually see the thing I built.

That’s distribution. And it’s pretty much the whole game.

The project that finally drove it home for me was Whisper Money. That’s where it clicked: the building was the easy part, and getting people to find it was everything.

You can build the best product on earth and watch it die quiet because nobody ever found it.

Here’s what makes it worse now. AI writes half your code. Building has never been this easy, so everyone is shipping something.

The hard part stopped being the building a while ago.

⁠

The hard part is getting found.

So if you only learn one thing this year, don’t make it another SaaS.

Learn how to put your product in front of people. Otherwise you’re just talking to yourself.

The other day, a designer made their first code change in the product.

This is proof that the ability to write code is becoming less important.

It’s also becoming more horizontal.

Anyone with general computer knowledge, will be able write code using AI, create a pull request, and launch a feature.

If that’s all you can bring as a programmer, you’re fucked.

⁠

In the coming months, designers won’t be the only ones making updates.

Product owners and even customer support will also be able to launch their own changes to the product.

So if the only thing you can do right now is receive a ticket with a description and turn it into a pull request, you are fucked.

⁠

Now more than ever, being a programmer has to mean something more.

It means being able to read production logs and spot optimization points, identifying bottlenecks, figuring out what’s consuming the most resources, and pinpointing the parts that are performing poorly for users.

It also involves product knowledge: thinking about how we can make the product more useful, solving user problems more effectively, and pulling the right levers to boost our product’s ARR.

As a programmer, you also need to start learning and understanding how servers work, how deployments work, and the different CI and CD processes.

All of these areas are where AI isn’t reaching yet, so you have to know how to control them.

⁠

I don’t want to alarm you. I’m a programmer too, but honestly, junior developers and mid‑level engineers who only take tickets and submit pull requests are in trouble.

If you want to stay competitive in the market and keep progressing, you need to go one step further.

If you’re not clear on that, writing code today isn’t a blocker at all.

Launching products is easier than ever, and adding new features or filters to your product is just as simple.

The key is getting your product to the right audience—and to as many people as possible within that audience.

If you are a developer like me, and you are focused on features, code quality, speed, performance, frameworks, programming languages, and all that stuff.

You’re mistaken.

I noticed all of this with Whisper Money.

I started this product about six months ago. The product is complete and functional. It covers a real need. It’s also attractive and easy to use.

But it wasn’t until I teamed up with a partner who handled marketing and distribution that the product started to take off.

As of today, our MRR keeps climbing.

Every day we’re gaining more users, getting more feedback, and building a bigger community.

And finally, it feels like the product is really starting to click.

Three accounts. A Binance wallet. An apartment I rent out. An index fund I’d forgotten about.

No app on earth could show me the real picture. So I went back to my spreadsheet. Again.

That night I started building Whisper.money. Alone.

Four months in, I hit a wall.

The product was good. But a great product nobody hears about is just an expensive hobby.

So I called Álvaro — a YouTuber I respected, with a real community and sharp instincts for what people actually want.

He said yes. Now I build, he brings the world in.

Here’s the thing nobody says out loud.

Budgeting apps don’t make you richer. They make you organized.

There’s a difference.

Most apps show you what you *spent*. None of them show you what you actually *own* — across banks, crypto, real estate, funds, the whole mess.

And the ones that try? They sell your data to do it.

We’re building the opposite.

🐤 Whisper.Money — three things that make it different:

- Everything in one place. Banks, Binance, Bitpanda, real estate, index funds. Your full net worth. Not just last month’s coffee spend.

- Actionable, not decorative. Pretty charts are easy. Telling you *what to do next* is hard. That’s the whole product.

- Your data is yours. No selling. No sharing. No third parties. That’s why it’s called Whisper.

We launch May 4th 🗓️.

Bank connections cost real money, so we can’t make it free. But the first 100 users on the waitlist get early access + a free discount forever at won’t come back.

Move up the queue by inviting friends. Simple as that.

🔗 Join the waitlist → https://whisper.money

I’ve worked nights, weekends, and every gap between 9 and 5 for six months to build this.

Not because the world needs another finance app.

Because it needs one that actually tells you the truth.

— Victor

I need your help.

I’m working on kaiden.chat, an AI personal nutritionist and fitness coach, and I need testers on Android.

With Kaiden you can log meals with text or photos, get instant calories/macros, personalized meal suggestions, and adaptive workout plans, all synced across devices.

We’re inviting 🤖 Android users to join our private test and help shape the app. Install the app and share feedback directly with me at victorfalcon@duck.com.

Everyone who signs up now gets a free, forever, unlimited license.

Sign in now:

• Android: https://play.google.com/store/apps/details?id=chat.kaiden.twa

• Test signup (web): https://play.google.com/apps/testing/chat.kaiden.twa

Thanks,

This powerful Laravel boilerplate enables you to create your SaaS product with a single command, saving you precious time and allowing you to focus on what truly matters: solving problems for your users.

Why Laravel Shipper?

In the fast-paced world of software development, time is of the essence. Laravel Shipper is designed to help you launch your app in days, not weeks or months. With just one command, you’ll have a fully functional application that includes:

• Authentication: Secure user login and registration.

• Billing: Integrated payment processing to handle subscriptions and one-time payments.

• Lifetime Licenses: Offer your users the flexibility they need.

• Leads Generation: Capture potential customers right from the start.

• Beautiful Landing Page: A professional-looking page to showcase your product.

Focus on What Matters

With Laravel Shipper, you can concentrate on the problem you’re trying to solve instead of getting bogged down by the generic setup processes that don’t add value to your business.

Do you have a brilliant idea? Create a landing page in less than an hour and start capturing emails from interested users—or even better, start selling licenses!

There’s no better way to validate your idea than to get it in front of potential customers quickly.

One Command, Two Code, Three Launch!

Why wait? Get Laravel Shipper today and make your first dollar online!

Stop spending days on a project that may not resonate with your audience.

Launch a landing page now, validate your idea, and start your journey toward building a successful SaaS business.

Pricing

You can purchase a single license for $29.99, or an unlimited for $109.99. This prices will increase soon.

Also, because your are subscribed to this newsletter, with the code VICTOR25, you can get an extra 25% discount until Friday 8th.

The good thing about it, it’s not a project you have to clone, it’s just a Laravel package you have to install.

ℹ If you want to test this boilerplate for free, write me on this tweet.

You can continue using Laravel as you have been doing until now. It’s just a single command that will provide your project with:

• Authentication.

• Monthly or Yearly subscriptions with Stripe.

• Single Pay Licenses.

• UI Components and an already build landing page with:

  • Company logos.

  • FAQ.

  • Prices.

  • Testimonials.

  • … and more.

• Legal pages: privacy policy and Terms of Services.

And, the best thing.

You can use Blade, React, VueJS or InertiaJS with or without Typescript.

Would you use something like this?

Do you want to access the first beta for free?

↪ Write me on this tweet.

If you follow the project, since the beginning it has gone through several different phases.

• I started fully on the project, super motivated and active. I dedicated time to it practically every day and the pace of updates was frenetic.

• As time went by, I was still motivated, but I focused more on getting users and increasing MRR.

• Then, there were problems, the costs of the service increased and the MRR did not take off, and the project became half abandoned. Consider selling it, making it open source, closing it, etc.

In the end, after a few months of inactivity, the project returns with more enthusiasm than ever.

Monse has been partially acquired

Two people, with a lot of potential and experience in the sector, have bought a large part of the application with the intention of taking it to the next level.

I still maintain a part of the application and I am still an active part of the development, although I am no longer alone.

They have great ideas that we are currently working on.

• First, we are going to add more bank providers to the platform and will be compatible with banks in the United States and Canada, in addition to adding credit cards and loans. The idea is to reach beyond my Twitter account.

• We want to add budgeting functionalities and detect recurring charges like those that come from subscriptions (Netflix, Spotify, etc.)

• We are going to improve current compatibility with bank in EU. Right now we are having some problems creating new connections.

• We are going to relaunch iOS and Android app. Maybe we can add some widgets to the Android app too.

• We are going to invest in ads, and focus on USA market. The idea is to reach beyond my Twitter account.

We will see how everything progresses, it is too early to draw conclusions, but I am sure that Monse will become the best tool to manage your assets.

If you are interested in knowing the full story of this acquisition and how the tool evolves, subscribe and, of course, register in Monse.

Today I want to share with you some companies that are applying this transparency to its core.

The first company I saw that practiced this was Buffer. Buffer it’s an open company since day one and they are sharing their salaries publicly.

Here you can see all the buffer employee’s and his salaries. And even more, they created a salary calculator so you, and everyone, can know how much they will earn working for buffer.

For me, it’s the perfect company mindset. No more people earning more than you just because they negotiate their salary better than you. Your salary depends in your level as a developer and your location (cost of living).

Another companies sharing salaries are Ghost CMS, Gumroad, and Keepler who also has a public Salary Calculator.

My Salary evolution as a Developer

As a person who likes transparency, now it's my turn.

This has been my salary evolution as a programmer from my first job to my current one.

I have been working as a Developer for +12 years now and this have been my career until now.

I moved from Gran Canaria to Madrid to work at Clever Consulting, a small agency where we make websites mainly with WordPress and Prestashop. We also did some tools with Ruby on Rails. I learned a lot, it was my first job.

Then I moved to Chicfy and from Madrid to Malaga. Chicfy was a small start-up that was competing with WallaPop and Vinted. At the end, Vinted bought us. It was my first job at a startup and I love it. I discovered myself as a product developer.

My next step was Wallbox. When I joined it was a “small” company with about 15 developers, and after 4-5 years it became a huge company with more than 50 developers. There I learned a lot about how to scale, how to work with microservices, event driven design, hexagonal architecture, DDD, and more.

After 5 years I received a bug offer from Spryker, an offer that I can’t reject, but I should. At Spryker I was not happy, I was working on a demo team and I were not working on the product itself. I was not working on what I like. That’s why I left after less than a year.

Right now I’m working at AltoVita, a company based in London, but working from home. It’s too soon to tell you anything, but I feel super happy here, working on the product, and try to improve it as much as I can since day one.

One more thing

I have some important news about Monse. A few days ago a I signed a contract with some interesting changes in a company level.

I want to wait a few days before giving details, but that will be my next post so, share this one and subscribe.

Subscribe now

I did it when I was earning 1,200 a month and now that I am earning 4,000.

I don't do it out of arrogance, I don't think I'm better than anyone else, but before when I said it, nothing happened and now there are people who resent it.

If I have a good salary and I share it, I am a conceited person, if I have a normal salary and I share it, I am not.

When I am with a person in private, I don't shout out my salary, but if he asks me I tell him without any problem.

On Twitter, I post whatever I feel like, I don't think about a specific person, so I just blurt out these kinds of things and others without thinking too much about it.

The reality is that I believe in salary transparency.

I think we are the employees who benefit from it and I think we should share it more.

Sharing your salary favors the elimination of the gender gap and avoids discrimination.

It also gives more bargaining power to workers, and favors fairer salaries within the same company and outside it.

And, believe it or not, there are companies that publicly share the salary of all their employees, and everyone knows how much the person next to them earns.

I am preparing an email in which I will show you the evolution of my salary from my first job to my current one.

I will also share with you some companies that practice this salary transparency.

Leave me your email and share this article, I'll let you know as soon as I publish it 😉.

Subscribe now

MetricsWave was making sales three days after starting development. A week later he had already sold $300 worth of licenses.

Launching quickly is one of the best decisions you can make when creating a SaaS. The sooner your product is in production, the sooner you will start to get feedback.

So, how can you launch your product in days instead of weeks?

1. Choose the right stack

In my case, I make all SaaS with Laravel and React.js or Laravel Livewire, why? Because is the framework I already know and the one with I’m faster.

Although, Laravel with gives me some starter kits with which I can have registration, login and user profile in a second.

And with Laravel Cashier I can connect Stripe, and start receiving payments in minutes.

But in your case it may be different. If you don't know PHP or Laravel, you may be faster using Ruby On Rails, Node.js, or any other language or framework.

Let me tell you something: Nobody really cares. Seriously, there are no users who care what language or framework is behind an application.

The advice is clear, use the one with which you are most comfortable and fastest.

2. Define the right MVP

Ok, now you know how to build it, but what are we going to do?

Ok, now you know how to build it, but what are we going to do? I'm not talking about the idea, I'll leave that to you, but about that idea, what is essential and what is not?

What is the minimum we can do so that the user has a functional tool that solves their problem? That’s the question. Everything else should be built after launch, not before.

I'm going to tell you a secret. As of today, months after launch, MetricsWave does not have any limitations on free accounts.

You can pay and upgrade your account plan, but free accounts only see a warning when you exceed the limit. The rest continues to work exactly the same.

Why? Because that’s not my focus right now. My objective it’s to keep improving the application a make sure that it solves the problem of having good website analytics in a convenient and privacy-friendly way.

So, in summary, build only what is essential. Think about the problem and solve it. The rest will either be done or not.

3. Use the right tools and APIs

You don't need to reinvent the wheel. There are tools out there that can make the entire process easier.

You can use the Stripe Customer Portal to allow your users to manage their subscription and payments. Or the Payment Links to start receiving payments without developing anything.

Do you need an application, or can it start with just a form? Can you solve the problem with a few emails?

Maybe you can solve the problem creating a basic shop with Shopify, or sell your content with Substack.

Check if there is the perfect tool for you and the problem you want to solve. Most of the time it is not necessary to program an ultra-complex tool.

4. And, the most important

If you want to make sales, this is the best advice I can give you:

You don't really need a product to start making sales.

Believe it or not, you can sell without having an app or a product.

Knowing how to explain the problem and what the solution will be like already gives value and can make many people end up buying future licenses for that app.

With MetricsWave I achieved sales before launching the product. It was just a landing page explaining what I was going to build and what the tool would be like.

I also promised to do it if a certain level of sales was reached or return all the money otherwise.

Also create a roadmap to explain when the initial version would be available, what features it will have and when the next new features will arrive.