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.

You can decide to put all the code in the controller, you can create use cases, DDD, or use jobs to host all your logic.

Thanks to developerjoy.co I have been able to work on dozens of different projects and I have seen first-hand what makes a Laravel application easy to maintain as it grows.

For me, if I had to keep only three keys, they would be the following:

Table Of Contents

• Use Events and Listeners

• Tests everything, it's super important

• Embrace DDD and create Modules

Use Events and Listeners

It is very common, in all applications, to have to do something extra after a simple use case.

For example, send an email, after creating a user.

This type of case tends to dirty our use cases and forces us to add more and more logic. In addition, we make the use case slower and slower, and the user has to wait longer.

Why does the user have to wait, when they register, for us to send an email?, for example. Has no sense.

To avoid this and keep our use cases clean, you should use events and listeners.

Create a UserCreated event and a SendWelcomeMailOnUserCreated listener.

Every time you need to do something else in a use case, you will simply have to create the listener. Your use case will be able to continue working as is, without any changes.

Tests everything, it's super important

I know, making tests is boring and a waste of time. Really?

Apart from making sure that the basic use cases still work, it will also help you keep your code clean. You do not believe me?

If you test your use cases you will be able to refactor the code when and how you want without breaking anything. This is something of a superpower.

Do you want to simplify your use case and start launching events? Do you want to move your site code? No problem. First write a test and then you can play what you want with the assurance that you are not breaking anything.

Plus, testing in Laravel is easy.

Most of the time, testing an endpoint is just a couple of lines. It's easy to make and quick to execute.

Really, there is no turning back. When you prove the value that the tests give you, you will not stop writing them.

Embrace DDD and create Modules

When an application with Laravel grows we find many models, controllers, events, listeners and jobs together in the same folder.

This makes it impossible to have a context of what is happening with our model.

Imagine that you are working with the user, and you need to update a use case, the registration case, for example.

By having everything together it is impossible, at a single glance, to see everything that affects our user model, in which controllers it is being used and what events it launches.

Using DDD, you will separate your code into modules and be able to see at a glance what you are working on.

Personally I like to create a src folder and there create a Module for each model or entity.

In the end it would be like this:

/src
   /Users
      User.php
      /Listeners
      /Controllers
      /Events
      /Providers
      ...
   /Posts
      Post.php
      ...
   ...

Believe me, in the end, as your application grows, you will appreciate it.

After three weeks or so with the project paused I still think it makes sense. I still thinks that the product can make money, be useful, and find his niche, but with a few changes.

That’s why I posted this a few days ago.

A simple message that got a lot of interactions. I received +10 DMs and replies of people interested in helping me with the project.

Some of them wanted to work with me while others wanted to talk about the current status of the project, make me think, and give me ideas.

One of these ideas was key.

What if Monse, instead of being a banking aggregator, is a tool focused on helping you save?

Next week, we'll explore this idea here.

A newsletter with over 12,000+ of startup founders, business owners, and indie makers.

Here you can find the ad it self.

Before of sharing with you the actual metrics and results, how many sales/leads do you think I got from this ad? Write it down before continuing.

First of all, let’s see the traffic.

I’m using MetricsWave 🌊, to monitor all the traffic at DeveloperJoy.co so here are the screenshots you are waiting for.

• The spike is real, usually it doesn’t receive a lot of traffic, so the traffic from the ad was noticeable.

• As you can see, from this campaign, I received 97 new visits. About $3,08 per click.

If it is a lot or a little, if it is worth it or not, it is something that you must decide.

In my experience, I have ever invested in worse campaigns with a lower CPC.

As for the amount of traffic, it seems correct to me.

And, How many leads and sales have I gotten?

Now it's when the tricky parts begins.

We are going to give the data, and then we move on to the explanation.

With this ad I got no leads or sales.

But, maybe, it’s normal. I mean, it’s an expensive product. The cheapest plan is a $3,995 monthly subscription. So it’s not something you can buy without thinking about it.

At least, right now, there are about a hundred more people who knows about DeveloperJoy and how it offers.

Three years ago I started my first adventure creating a product as an Indie Maker.

I thought it would be something simple, it solved a personal problem and it seemed that people would be willing to pay for it, but I found myself with the reality.

During these three years I have not succeeded yet, but I have learned two lessons that I consider very valuable.

It's not easy to be successful

When I say success, I mean generating +1k/m (over $1,000 per month).

Despite the numerous success stories you come across, they represent only a minority.

Many projects, if you observe them from the beginning, eventually fade away after a year or two.

Just take a look at old projects on Product Hunt; they speak volumes.

Challenges are Inevitable

There are always problems, always.

Let me share my experience with my first SaaS, Monse – an app designed to connect your bank and help you spend your money efficiently, maximizing savings and investments.

What initially seemed like a small and relatively simple project eventually became more complex.

The banks' APIs didn't work as they should, and many users encountered difficulties connecting their accounts, fetching transactions, checking balances, and more.

Learning from this lesson, I embarked on creating my second product. MetricsWave – an event-based alternative to Google Analytics.

This time, I aimed to develop a solution that didn't rely on APIs or third-party services.

However, I soon encountered another hurdle – ad blockers.

For no apparent reason, ad blockers started blocking my domain.

It wasn't even a script to track visits; it affected the main domain of my landing page.

If you have one of these extensions installed and visit the landing page, you will encounter something like this:

This issue, yet again, is beyond my control and hampers the user experience I intended to provide.

Presently, I am actively working on finding a solution. Only time will tell how it turns out.

Conclusion: Embrace the Journey

Throughout my experience in creating SaaS, one thing is clear: something unexpected will always happen.

It is crucial to stay motivated and passionate about what you do; otherwise, you may give up at the first sign of a problem.

Starting a venture solely for money or success is not the right approach.

Enjoying the journey is essential because the reality is that the chances of not succeeding are very high.

Remember, the road to success is paved with challenges and obstacles.

Embrace them, learn from them, and remain dedicated to your vision. It is this unwavering dedication and love for the process that will drive you forward, despite the odds.

The repository pattern consists of adding a layer of classes that is in charge of accessing the data source and obtaining the different data models.

They have methods like find, findAll, create or update among others and they are very common in frameworks like Symfony but not so much in Laravel.

There are articles, videos, and even libraries for implementing this pattern in Laravel, but does it make sense?

Laravel is Active Record

In Laravel we have Eloquent ORM is based on the Active Record pattern and Doctrine, from symfony, is based on the repository pattern.

In the active record pattern , each model corresponds to a table in our database, and this model itself is our way of accessing this table. We can search, create or update records in the table using the model directly.

<?php

// Obtener el usuario con id = 1
User::find(1);

// Algunas forma de buscar/crear usuarios
User::all();
User::where('email', '=', 'hola@victorfalcon.es')->first();
User::create([ ... ]);

This has caused many people to classify active record as an anti-pattern. Specifically, it breaks with SOLID's Single Responsibly Principle , since each model is responsible for both interacting with the database and its relationships, and also, being a model, it also contains some domain/business logic.

And I don't know if you agree with this or not, I have my opinion, but what you don't have to EVER do is mix both patterns.

Repository pattern in Laravel

For starters, wanting to apply this pattern in Laravel, with Eloquent ORM already sounds very bad. We are making an active record based library work like a repository based ORM when one has nothing to do with the other.

But hey, we are stubborn, we want our Laravel application to have repositories, let's get to it.

Create our repository

Let's create our own UserRepository that will look something like this:

<?php

namespace App\Repositories;

interface UserRepositoryInterface
{
    public function all();
    public function create(array  $data);
    public function update(array $data, $id);
    public function delete($id);
    public function find($id);
}

<?php

namespace App\Repositories;

use App\Model\User;
use Illuminate\Database\Eloquent\ModelNotFoundException;

class UserRepository implements UserRepositoryInterface
{
    protected $model;

    public function __construct(User $user)
    {
        $this->model = $user;
    }

    public function all()
    {
        return $this->model->all();
    }

    public function create(array $data)
    {
        return $this->model->create($data);
    }

    public function update(array $data, $id)
    {
        return $this->model->where('id', $id)
            ->update($data);
    }

    public function delete($id)
    {
        return $this->model->destroy($id);
    }

    public function find($id)
    {
        if (null == $user = $this->model->find($id)) {
            throw new ModelNotFoundException("User not found");
        }

        return $user;
    }
}

And finally we will create a repository service container in which we bind the interface to the repository implementation so that we can then inject where we need it.

public function register()
{
    $this->app->bind(
        'App\Repositories\UserRepositoryInterface',
        'App\Repositories\UserRepository'
    );
}

As we can now see, we have encapsulated all the access to the data in a specific class and we can now stop using the model for this, although, in reality, our model continues to have the same methods and the repository depends directly on the model and that it has this inheritance. with Eloquent.

And the question is:

• Me — Have we won something? Is there a difference between do User::all()or do $this->repository->all()?

• Symfony dev — Well, even though we're increasing complexity and, even worse, duplicating code, we can now mock the repository and do tests without accessing the database, and that's cool!

• Me — True, but if that was your problem, I should have said it before. That is solvable and we don't have to change Eloquent to achieve it.

Why doesn't it make any sense?

Most of the time someone rejects active record it's because it's not testable , you can't test a simple class without having to set up a database, since there is no way to change or replace the model that is part of our domain code and we need to test.

And this would be a big problem if, in Laravel, it wasn't so easy to do a test with the database.

As we see in the following test, Laravel comes prepared to do this type of automatic tests in a simple and clear way and, with Laravel Sail, we don't even have to worry about Docker containers .

use DatabaseMigrations;

class UserCreatorTest extends TestCase
{
    use DatabaseMigrations;

    private $service;

    protected function setUp(): void
    {
        $this->service = new UserCreator();
    }

    public function test_it_creates_an_user(): void
    {
        $data = [
            'name' => 'Víctor',
            'email' => 'hola@victorfalcon.es',
        ];

        ($this->service)($data);

        $this->assertDatabaseHas('users', $data);
    }
}

In addition, the latest versions of Laravel are even prepared to launch these tests in parallel, making them run faster and time is not a problem.

And finally, these tests provide us with much more value than unit tests without infrastructure and, in most cases, even if we do unit tests, we will also have to do functional tests with the database to make sure that everything goes as expected.

Conclusion

In short, we have to assume that unit tests in Laravel are not common, but that doing functional tests is a matter of seconds and therefore, we adopt the facility of active record.