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.

MetricsWave, a Google Analytics and Amplitud alternative, has recently been added to the block lists and the home page and web application has become inaccessible.

The problem is that, right now, all users who have an ad blocker extension installed cannot access our landing page or web app. The will see something like these.

I can understand that they block the tracking script, but this doesn't seem right to me.

They are blocking my entire website!

Other competitors like Google Analytics or Plausible sites are not blocked.

How am I supposed to compete with other tools being blocked?

Table of contents

1. How could this happen?

2. What options do I have now to solve this problem?

1. How could this happen?

I really had no idea how this world worked. There is always a first time for everything.

Something, so important, that can do so much damage to a business, depends only on one person.

One person who, by adding your domain to a text file, can make 65 million people unable to access your website.

It's as simple as that.

And the worst part is that you can't do anything about it. If this person doesn't want to remove your domain from the list, you're screwed.

In my case, this was the list.

You can see information about who is blocking a domain in the extension, in this case uBlock Origin.

2. What options do I have now to solve this problem?

The first one and simple is to talk with the author of that list.

Send him a message, try to be polite, and explain to him what is happening. I explain to him that he is blocking all my sites and web applications, not just the tracking script.

What he replied is that he couldn't block the script alone if he was serving it from the same domain, so I proposed to move it to a subdomain, and he was fine with that.

I have been lucky.

Another option is to open an issue in the uBlock Origin extension repository on GitHub. But trust me, if you have to do this, you're in trouble.

They are not polite; most probably, they are going to discard your issue and tag it as "won't fix" in a few hours.

tl;dr Fintonic is insecure and sells with your bank details. They save the username and password of your bank having full access to it. In the event of a hack or a disgruntled developer, anyone could break into your bank and take your money. Monse has an opposite philosophy.

Let me tell you how Fintonic works and why you should never use it.

We agree on one thing. Your bank details are GOLD. If someone could break into your account it would be a catastrophe. Not only would he have access to personal and private information, but he could extract your money, ask for loans, and know what else.

Knowing this, if I asked you for your username and password to access your bank account through the web, would you give it to me? That is what Fintonic does.

How does Fintonic access your bank details?

To access my bank (ING), I have to enter a 6-digit security code and my ID. Just the data that Fintonic asks me to connect my bank.

These data will be stored in the Fintonic database in plain (or at least decryptable).

In the event of a data breach or, even easier, a disgruntled programmer, your data could be leaked and anyone could break into your bank impersonating you.

How does Fintonic make money?

This part is also very easy. Fintonic is a free product, nobody pays to use it. Right now they offer a bank card with which they will be earning money thanks to an agreement with a bank or similar, but this was not the case some time ago.

Fintonic makes money by selling your personal data to third parties and you can see it clearly in its legal terms .

Why is monse.app different?

https://get.monse.app

Let's be clear, I'm the creator behind monse, I'm not biased. But everything I tell you about monse below is true. If you have any questions write me on twitter .

At monse we do not ask you for your username and password at any time, we do not want to have such dangerous information. At monse we use the API of your own bank to obtain bank details.

So that everyone understands why the word API is very technical, this is the process:

1. You tell your bank to give us read access to the transfer history and balance of your accounts.

2. The bank gives us a code that lasts about 30 days (depends on the bank) and that we keep.

3. With this code we can tell your bank to give us your reading history and balances and it is your bank that verifies who we are, that the code is valid, that it has not expired and that you still allow access. If all this is true, your bank gives us, in text, this data.

4. After 30 days, when the code expires, if you want us to continue accessing your data, you will have to connect it again.

As you can see, the process is very different.

Monse do not have any control, we cannot do anything without you and your bank knowing. It is your bank that is in control at all times.

Also, we don't have any username or password. We could not, in any way, enter your bank through the web as if Fintonic does.

And how do we make money?

All the money we earn comes from users who decide to pay a monthly fee to get extra features, nothing more.

We make it very clear that we do not sell or share your data with third parties . We understand that the data is yours and not ours, therefore, we do not market with them.

Bank transfers and balances, mainly. These are relevant data, but on their own, without being able to associate them with a specific person, they are worthless.

Here is an example:

So, clearly, I have to make the person behind each account unidentifiable in order to achieve anonymity and, therefore, make the data irrelevant.

How do I create an anonymous account on Monse?

Because user privacy has been crucial to the project from the very beginning, the only personal information stored in monse is the user's email address.

The email is fundamental, to be able to log in and out of your account, but it doesn't have to be a way to identify you. There are several options:

• If you have an Apple device, you can use the option to hide your personal email.

• DuckDuckGo also has a service called Email Protection (currently only in private beta), which allows you to hide your email.

• Or simply generate an email without any personal data that only you have access to and know about. Remember that you have to have permanent access (temporary emails are not useful), because when you want to enter your account again you will receive an access code that you will have to verify.

And that's it, you don't need anything else. In monse we don't have any other data with which we can identify the person behind the account.