Forem: Lucas Lima do Nascimento

Super glad to have put that one out! Check it out if you're looking to learn a little more about architecture! 🚀

Lucas Lima do Nascimento — Mon, 02 Dec 2024 14:53:00 +0000

From Monolithic to Microservices: Architectures 101

Lucas Lima do Nascimento for Encore ・ Dec 2 '24

#webdev #beginners #architecture #programming

From Monolithic to Microservices: Architectures 101

Lucas Lima do Nascimento — Mon, 02 Dec 2024 10:10:00 +0000

Introduction

Hello there, dear reader! Well, if you’re reading this I assume that you probably have already a basic understanding of how the web works and you probably got a few things done by yourself as well, so congrats on that!

The next big step is to understand a few of the patterns and architectures that exist out there. Not only that will make your software building more consistent, but also, way more solid too — from scalability to maintainability.

This article will explore two of the most popular software architectures: the monolithic architecture and the microservices architecture (with some other important concepts in between).

As always, we have a bunch of discussions regarding which of them is better and the answer here is as always the same: there’s no silver bullet, you should learn which are the cases for using each of them and how to transition between both as well to be a rational engineer.

First one: The Monolith

In case you’re unfamiliar, the monolithic architecture is one of the most traditional ways to design software applications. In this approach, an application is built as a single unit — which we call the monolith — where the components of the software are interconnected and interdependent.

This architecture is characterized by a single codebase (usually using the MVC pattern), shared database, and typically a single deployment unit.

Advantages

Monolithic applications are often simpler to develop, especially for smaller projects or teams. They have a straightforward development process since the interactions between different parts of your application reside in the same place — this also means that there are generally fewer API calls and fiddling data around to make stuff work!

In terms of deployment, it generally is easier as well. Since you have a single unit, once you deploy it, everything should be up and running, meaning you don’t have any extra work on that.

When we talk debugging, it is generally simpler because the entire application runs within a single unit (which means you generally don’t have to jump around between multiple applications, trying to find the problem). End-to-end testing can also be easier and can run smoothly through entire journeys.

Disadvantages

As the application grows, a few challenges start to appear. The first one is organization-wise — since everything is in the same place keeping the context of a really big application and all the ramifications it goes through starts to become really hard (of course, there are ways to plan ahead — e.g. the Modular Monolith, for example — for that, but, when you build fast, this generally are not thought through).

The second one is scaling per se. Since the whole application is inside a single unit, specific usage-intensive points of your application will share the same resources as your whole app. This generally means that scaling things becomes a more complex task than just “pay more server power” or “rewrite that part in a different tech”.

Microservices Architecture

Now, the general alternative to a Monolith is the Microservices architecture. It’s an approach to developing a single application as a suite of small services (that’s where the micro comes from), each running in its own process and communicating with lightweight mechanisms to keep it all running. They can usually be developed, deployed, and scaled separately. Each service typically has its own database and communicates with other services through well-defined APIs.

It also has its own patterns of organization (which there are a ton of famous books about) where one of the most common ones is DDD (Domain-Driven Design).

Advantages

The first and most obvious one is scale. Microservices can be scaled independently, allowing for more efficient resource utilization throughout the segments of your app. Since everything has to communicate as a black box, this architecture also provides flexibility in choosing technologies for different services.

The second one is that when we are talking about really big apps, the complexity of the code of microservices is distributed between them. This generally means that, if a microservice has a bug, it’s simple to send a new engineer of the team to go take a look at it — there’s not that much space where this bug can exist anyway.

Disadvantages

The first one is that making all those things communicate and interact properly can be a real challenge. God only knows how much time an engineer is capable of spending trying to find why messages from Kafka are not arriving or any other weird problem that can happen. Managing all that, their infrastructure, and deployments can be hard.

The second one is that the context is more segmented — this can be a good thing when we look at it coming from the point of view of learning the code base, but this can be a pain when looking at it as learning the product — it’s way easier to follow if your code goes through 5 files than 5 different apps.

The last one is that microservices have a caveat which is Latency. If they’re not designed properly, it’s quite possible that the separation of concerns and expected speed increase will not pay off since now you also added a bunch of different calls for them all to communicate.

And sometimes, when people create new stuff, they try to fix part of those problems, which is part of the feature set of Encore, the sponsor of this article:

A great standout feature for me is that you don’t need to worry about the communication between different microservices as much as you’d normally have to. It’s a really great idea — you have almost the same developer experience as when you’re working with a monolith, but, with all the scaling power of a microservice.

In this case, for example, you can call a service from inside another one by simply importing it

There are also a ton of features to make the deployment process of multiple services easier as well. They’re really trying hard to make that bridge of having the best of both worlds happen and it would be awesome if you could check them out and give them a star!

⚡ Star Encore ⚡

Choosing the Right Architecture

When deciding between architectures, you'll need to consider your application's growth potential, team size, and how complex your product actually is.

The simpler your app is, the more you can benefit from a monolithic approach. If you’re in doubt, the safest choice is going with a monolith — you can always break things apart later, but, stitching things up is HARD (here’s a great source to read if you’re still in doubt: Monolith First)

Architecture	Key Benefit	Key Disadvantage	Best For
Monolithic	Simplified development, deployment and debugging	Growing issues	Small to normal-sized applications and MVPs (e.g. DEV.to is a monolith!)
Microservices	Independent scaling of components	Complex management	Really large applications with multiple teams (e.g. Netflix uses a ton of microservices)

As complexity grows, you might want to consider breaking things apart, so, let’s talk a little bit about how can you convert a monolith into a series of microservices.

Converting: How to migrate from monoliths to microservices.

There are a few ways to migrate from a monolith into the microservice world. Let’s quickly go through them:

Greenfield Replacement: Simply creating things from the ground up — not having constraints from prior work can be really beneficial in some cases. But, of course, we have a bunch of inherent possible problems here (how long will it take? how much time will users suffer? etc)
Brownfield Replacement: New architectures should coexist with live software. When we’re talking about brownfield replacement, there can be a lot of pain and headache in coexisting things with old/problematic software. An interesting approach to solve on how to tackle this problem is the Strangler Fig pattern, where, we’ll generally wrap, little by little as a strangler fig, the old code and redirect it to newer code, eventually killing it. This makes the transition more smooth and also less risky.

Generally, here are the steps we are going to take:

Identify clear boundaries within the existing application.
Gradually extract services, starting with less critical components.
Implement new features as separate services
Refactor the existing codebase to support the new architecture
Ensure robust testing and monitoring throughout the migration process → Nothing is as hard as changing your application blindly

Conclusion

Hey! We've gone through quite a journey here. We talked about two main architectural approaches: the good old monolith (simple, and straightforward, but with growing challenges) and microservices (flexible, and scalable, but way more complex to manage).

I hope that you’re now able to choose things (or at least have a great gut feeling) for the next choice you’re going to make, but, remember: there's no "one size fits all" - if you're starting something new, go with a monolith first if not, think it through!

At the end of the day, what matters is picking the right tool for the job. Understanding these patterns will help you make better decisions for your specific needs. And remember: you can always change things later - just make sure you have a solid plan for that transition!

Choosing the Right Tech Stack: A Developer's Decision-Making Guide

Lucas Lima do Nascimento — Mon, 28 Oct 2024 14:00:00 +0000

Introduction

Hello there, dear reader!

So, you’re at that spot, you’re beginning a new project and now, you have to choose which technology to go for. Do you go for the old and more reliable ones? Or you try out the new hot product on the market to see if it holds up to expectation?

Well, it’s part of the engineering process to discover how to handle these situations, and, different engineers are going to have different takes on this — you’re probably even familiar with a bunch of opinions from different creators on which tech choices to use.

The truth is that you have to discover what works best for you (and more specifically for the project), and, for me, there’s a 3-step process for you to choose things in a more assertive way:

Evaluate the project requirements
Evaluate the learning curve & tech characteristics
Evaluate costs

In this article, we’re going to go through examples of all scenarios, and, in the end, you’ll probably be able to choose by yourself and discover your own process in the middle of all that.

Evaluating the project requirements

While in my degree studies, I had a great professor who once said:

The problem chooses the tooling, not you.

Are you creating a simple portfolio for yourself? A dog-pig identifier algorithm? A huge SaaS that will have to handle a ton of requests at the same time?

All those cases impact heavily on the tooling you’ll choose. You can build a simple portfolio out of anything you want, even check out a bunch of cool stuff and random libraries, just for fun. That might not be necessarily compatible with the huge SaaS scenario though — so, here’s the first step catch.

Before thinking too hard about what are the awesome stuff being released (being that new frameworks or just new releases of old frameworks), try to think in terms of exclusion by requirement: Is there any particular project requirement that might exclude a technology choice? If so, why? And please, try not to fall for imaginary problems made by fans of certain technologies — You’ll probably hear it all: X doesn’t scale, Y is better than Z, A is ugly (and to be fair, we all have our favorites). Your job here is to step aside, get your rational goggles on, and think rationally about your decision.

Here are a few examples of solid tech choices that might suit some case for you:

Front-end

I love front-end and one of the things that excites me the most is the amount of things being released into it. You might think that’s a burden and a problem, but, my take here is that whenever people create a new solution to a different problem, they push the bar further — making everyone along the way have to run to catch up. Here are a few front-end technologies worth exploring:

SvelteKit: Offers a compiler-based approach for building fast, efficient web apps
Qwik: Focuses on near-instant load times through resumability
React (and other meta-frameworks like Next.js): Known for its component-based architecture and virtual DOM
Angular: Offers a complete solution with two-way data binding
Vue (and other meta-frameworks like Nuxt): Praised for its simplicity and gentle learning curve
htmx: Allows for dynamic content without heavy JavaScript frameworks
jQuery: Still relevant for quick DOM manipulations and AJAX calls (and for checking out some legacy systems)

Back-end/Full-stack

On the back-end, there is a ton of great stuff being made, every iteration being more performant and even more focused on developer experience. Let’s check out a few projects worth checking out:

Ruby on Rails: Emphasizes convention over configuration
Laravel: PHP for Artisans
Spring Boot (Java): Provides a robust ecosystem for enterprise applications
Node.js: Allows JavaScript on the server-side
Deno (v2): A secure runtime for JavaScript and TypeScript
Encore: An open-source backend development platform that simplifies the entire backend development process, from API design to deployment.
Hono: A small, simple, and ultrafast web framework for Deno, Bun, and Node.js

The important thing here is that: these projects exist for you to try out new things and fall in love. New solutions to old problems appear all the time, so, what you’re trying to catch is what they offer you — if you’re convinced some tech gives you enormous value, which generally comes in the format of performance and DX, you might consider learning it a little more deeper to solve the problem at hand.

Evaluate the learning curve & tech characteristics

POV: You, learning a new tech for the first 11000 times.

The learning curve is a really important point to measure as well. How well do you or others on your team know certain technology? Are they familiar or have they just heard of it?

Short-term productivity

You have to take that into account because it will directly impact your productivity, and, by a consequence, your deadlines. If you have a really tight deadline, it might not be the perfect time to test an entirely new tool you’re not sure will solve your problem, so, ask yourself: Is the learning curve of this tool a big impact on our dates? Do we already have knowledge in close spectrums?

Questions like these might make you exclude a few other technologies based on time itself — you might have to pick up new stuff later, on a smaller project, and that’s okay. Remember that learning usually has a slow start and mastery takes time to get, but, it might pay off in scale and easiness of maintenance.

Community Support

Another important consideration when evaluating the learning curve is the availability of resources and community support for the technology you're considering. Established technologies often have extensive documentation, tutorials, and a large community of developers to turn to for help. Newer technologies, while potentially offering exciting features, may have more limited resources, which can impact the learning process and troubleshooting — it might be amazing at first until you have to code a full calendar by yourself.

Thinking long-term

Lastly, consider also the long-term implications of your technology choice. My take on this is that you have to really be aware of stuff that has not released a stable version — things can change a lot and the last thing you want is having to write an entire project again just because all APIs changed.

Considering the costs

Another important aspect of the decision-making process is considering the costs. There is a lot of tooling out there that, although they might seem awesome, the infrastructure to host them easily might make you lose your mind.

Try not to think here only in terms of monetary value too. If with one technology choice you might spend hours/days working on setting up the infra and with other is just commands, well, your (or your engineer’s) time is valuable and, every second you spend working on things that is not the product, is time flying by.

For me, this is an awesome aspect of Encore, the sponsor of this article:

One of its standout features for me is the simplified infrastructure setup. Want to deploy things super quickly using their platform and paying something for it? The option is there. Want to self-host your docker images on your cheap 5$ VPS? There are docs on that too.

Easiness of deployment and separation of costs/concerns with clients are really important features (Encore sets up AWS/GCP infrastructure in your own — or your client's — account, for example), and, unfortunately, not every tech choice out there works on that, so, stay aware.

A good rule of thumb on this is before coding and starting the project with a tech choice, give a quick overview of the deployment section (if it looks hard as hell, that might be a red flag).

⚡ Check out Encore ⚡

So yes, spare a thought on deployment and infrastructure costs and they might spare you a few pennies/dollars every month or so ;)

Conclusion

Hey! You got to the end!

Well, I hope that you now find choosing the right tech stack a more exciting journey, and not an impossible task! Remember — it's all about finding what works best for you and your project. By evaluating your project requirements, considering the learning curve, and weighing the costs, you're well on your way to making an informed decision (which is the whole point here).

Don't be afraid to explore new technologies, there’s a BUNCH of cool stuff being released every day for you to check out, but also don't underestimate the power of established tools listening to those same tech gurus that are not shipping software. If it delivers a good solution, matches you or your team's skills, and doesn’t cost you more than you can pay, you’re probably on the right path.

So, roll up your sleeves, dive into the documentation, and start experimenting! Who knows?

You might just find your new favorite tool or framework along the way.

30+ Awesome Repos For You To Start Contributing on Hacktoberfest

Lucas Lima do Nascimento — Tue, 22 Oct 2024 07:01:00 +0000

Introduction

Hello there, dear reader! Before we begin, this article is largely inspired by the awesome-for-beginners repo and the first-timers-only blog post which are great sources to keep in mind too!

Well, in the last few days, you might have seen a whole movement towards Hacktoberfest contributions — an annual event that encourages developers worldwide to contribute to open-source projects throughout October — and I really think it’s an awesome way to get you going with a bunch of different things, from experience to best practices, and don’t worry: there’s still time to contribute!

This was my first year contributing… I’ll probably write a little about my history with the event in other article though 👀

In this article, we'll explore 30 awesome repositories — and I’ll choose one for you if you think decision paralysis is taking the lead — that are perfect for contributing during this amazing event. Whether you're a seasoned developer or just starting out, there's something here for everyone and, to do that, I’ll try my best to sort those repos by interest! So, let’s dive in :)

How to Use This List & Tips for Successful Contributions

In the past, I’ve also written an article on how to start contributing, in case you want a quick deep dive on it, you can find it here. But, here are the essential points to get successful contributions:

Register yourself in Hacktoberfest: It is always important to remember to go to the Hacktoberfest website and put your name up there 🚀
Read contribution and event guidelines: Each project has its own set of guidelines (and so does Hacktoberfest). Make sure to read and follow them carefully — in repos, they are generally in the README or CONTRIBUTING files, so, this is the first place to check!
Start with beginner-friendly issues: Look for issues labeled as "good first issue" or "beginner-friendly" to get started and don't forget to comment/assign yourself to them.
Write clear commit messages and communicate with project maintainers: Your commit messages should clearly explain what changes you've made and why. A cool guide on that is Conventional Commits (just in case the repo itself doesn’t have a convention regarding commit formatting). Unsure about how things work on the repo? Don't hesitate to ask questions!
Create comprehensive pull requests: When submitting a pull request, provide a clear description of your changes and any relevant context — always remember: there’s another human being on the other side of the screen and they have a ton of other Pull Requests to review, so, make it as easy as possible for them to go through your modifications.

So, to use this list is a simple process: Go through the available categories, find one that you enjoy, follow the quick guide above, and go write some contributions!

Paralyzed by too many decisions? I’ve chosen one for you.

So, firstly, before we jump ahead in the categories itself, if you feel that you might get a little overwhelmed by all those repositories with different categories, I chose one for you to start contributing and overcoming the paralysis ;). It’s Frontend AI — a sponsor of this article, but also, a really really cool project and v0 alternative.

It’s super simple to contribute, simply go to the Frontend AI page, build a quick template enjoying the help of AI-assisted code, submit it through the Hacktoberfest button, and wait for a review!

The cool part here? You’re actually creating a reusable block of code that other people are going to be able to put on their websites with a simple click. To be fair, I still remember the proudness of delivering my first reusable component in a corporate environment and seeing it live, so, I hope you’d get the same feeling here.

⚡ Check out Frontend AI ⚡

THE LIST:

BTW, the really easy ones for you to start contributing are going to be marked with a ✅

Web Development

freeCodeCamp: An open-source codebase and curriculum for learning to code! What’s more delightful than contributing to learning? You can find more on this issue. ✅
Axios: The old-school (but not so much) way of making requests.
Jest: Want to get your hand on the testing side of things? Check out Jest!
Strapi: Interested in Content Management Systems? This one is a beast!
Excalidraw: Amazing project, I literally use this guy on an almost daily basis
You Don’t Need JavaScript: Great project to showcase the power of CSS by itself! Give it a look 😎
Appwrite: A really cool BaaS for you to go quickly on the backend side

Mobile Development

React Navigation: Routing and navigation for your React Native apps
Open Food Facts: Scan food products or their barcode to obtain data on ingredients, additives, and nutrition facts (this one hits home for me — I’m celiac, so it's super useful!) ✅
Fastlane: App (iOS and Android) releases made easy.
Termux: a terminal emulator application for Android OS extendible by a variety of packages.
NativeScript: Empowering JavaScript with native platform APIs.

Data Science and Machine Learning

Hugging Face: Transformers: State-of-the-art Machine Learning for Pytorch, TensorFlow, and JAX.
Julia: The Julia programming language!
Gradio: Build and share delightful machine-learning apps, all in Python. ✅
OpenBB: Investment Research for Everyone, Everywhere.
scrapi: This one doesn’t necessarily relate to data science and all, but, since scraping things is often a middle step, I think you might find it important too!

DevOps and Infrastructure

Kubernetes: Production-Grade Container Scheduling and Management — one of the greatest communities out there ;)
Grafana: Because Infrastructure needs observability ✅
Gitea: Self-hosted git, amazing project.
external-secrets: reads information from a third-party service like AWS Secrets Manager and automatically injects the values as Kubernetes Secrets.
Prometheus: The Prometheus monitoring system and time series database.

Miscellaneous/Cross-platform

GitHub Readme Stats: A cool and awesome way to make your README look great!
Auth0: Interested in authentication? Auth0 is a beast.
Home Assistant: Open-source home automation that puts local control and privacy first.
Free Programming Books: Freely available books! ✅
Cockatrice: Cross-platform virtual tabletop! Couldn’t make a list without a game related thing ;)
Developer Roadmap: Making a career path is hard, this, makes you easily navigate them.
HacktoberWall: A simple webpage, for you to put your name on and make a quick win! ✅
hoppscotch: An open-source alternative to Postman and Insomnia!
Awesomes: This one is a general idea — have a cool resource of some language? Share it in the awesome , e.g. Awesome Go!

Conclusion

Hey! You managed to get to the end and I hope that you found a cool/or a few cool repos to contribute to! It’s an awesome way to give a little something back to the community and feel free to make that Holopin that you’ll get shine!

Remember, open-source contributions are not just about code. They're about collaboration, learning, and making a positive impact on the global developer community — so please, take your time to grow and collaborate, showcase your work, and fly up high.

So there’s that. Take this to inspire you to, while we are at the end of October, get those last days to give those repos some love and make the world a cooler place!

Beginner’s Guide to Freelancing

Lucas Lima do Nascimento — Tue, 10 Sep 2024 19:24:43 +0000

1. Introduction

Hello there!

If you’re reading this, I assume that: you’re beginning to freelance (or want to) or you’re just looking for some tips in the process itself. Currently, I’m sitting at 6+ years of freelancing, and the intent of this article is to try to guide you through the different learnings I gained throughout those years.

Honestly, I can’t complain about the things I gained throughout those years — I started mostly for the experience (but, I’m not gonna lie that the extra cash always felt great) and I ended up with a bunch of different learnings besides sole experience: From developing a bunch of different ideas to communicating better with customers and even learning things I didn’t had an opportunity to put in practice.

These for me, are the greatest selling points for freelancing.

2. Getting Started: Customers

Literally the description the average customer is going to give you about what they want

First of all, we have to learn a little bit about customers. Here, we have 3 important topics to cover:

Finding and Securing
Negotiating
Legal stuff

Finding and Securing Clients

Let’s start by going over the first one: Finding and Securing Clients. This can actually be pretty hard — when I started freelancing I didn’t have a clue on where to actually find a customer, so, I started going into websites like Workana and Fiverr.

Did it work? No. Not only did I never get a client from those types of websites, but, to be honest with you here, that type of website always made me feel that the work I was doing creating software was cheap and disposable. To be fair, there are a bunch of developers out there who actually make money on this, so, maybe, it was only a misfortune on my end.

After that, I started to go through my friends to see if anyone knew someone who was looking for a developer, and in less than 2 days I had my first customer asking for a website, not a direct friend, but a friend of a friend. After finishing the work with this first client, he felt that the work was really good and spread the word — ever since I’ve never been without a freelance gig.

Here’s my first tip for you then: Don’t ignore mouth-to-mouth and organic reach. It’s tremendously powerful and can get you a long way! Ask your network and soon enough, people will start finding you. Don’t have a network? Start to build one (here’s a reference for you to start and you can try those websites while that isn’t ready).

A second tip? Don't necessarily accept your client's idea. They think they'd like an app, but maybe, the person would be better suited with a web application. You're the specialist, use your expertise (or reach out to others to better determine this) what is the best course here.

Negotiating

It finally happened, you found a client and they want software from you! Congrats! Now we jump to the second part which is negotiating. This is a crucial skill for you to gain as a software engineer (if you’d like to learn more, you can find more content about communication here).

Every single deadline you’re going to have is impacted by the capacity of negotiation of yourself and the people above you, in a corporate world.

Usually, when you talk to a client, they want a budget idea from you as quickly as possible — and here’s where things go bad, software time is HARD to estimate, so, if you rush things out here, there are only two possible outcomes: you overbudget it, and the client won’t like it or you underbudget it and you’re going to work for free.

Besides budget, they also want to know dates and time ideas, because they don’t have a clue if their project is going to take a week or a year and the cycle repeats, only two possible outcomes, or you’re going to cut short, having to work way more than intended or you’re going to put too much time for the client to be comfortable with.

Your job here is one: simply calm the heck out of this other anxious person you’re dealing with. They want to know things, and they want to know them fast, you just have to remind them that this is an engineering process and you’ll have to make some refinements before coming to the budgets and dates with precision.

Sometimes, you’ll find some clients that are especially anxious about wanting to know things, here, if you have done some freelancing before, you can try to eyeball a range to make them more calm. If you’ve never made freelancing and you feel that this client is this edge case, ask someone with freelancing experience how much you should charge and they’ll help you out.

Legal Stuff

Here’s a good thing if your customer is acquainted with you in some manner: you’re probably not going to go deep into the legal stuff! But, honestly, at least some contractual idea is generally necessary — everyone is great at demanding stuff, but not everyone is great at paying for the stuff they demand. Haven’t made a contract and your money didn’t arrive? Well, that’s bad — at least you learned something. The funniest implementation of a solution to this problem in my opinion is this one:

kleampa/not-paid: Client did not pay? Add opacity to the body tag and decrease it every day until their site completely fades away (github.com).

It’s important for you to get some sense into your country's regulations for taxes and informal jobs like this too. You don’t have to dig deep initially, but just learn a little bit about how things work and which taxes if any you should pay for.

3. Project Management and Engineering

Now that we've covered the basics of finding clients and handling the business side of freelancing, let's dive into the core of what makes a successful freelance software engineer: effective project management and engineering practices. As a freelancer, you're not just responsible for writing code; you're also in charge of managing the entire project lifecycle. This includes several key aspects:

Understanding and defining project requirements
Creating accurate time and cost estimations
Breaking down projects into manageable tasks
Using project management tools and methodologies
Show the progress weekly or recurrently

Usually, while in university, we have a whole 6-month discipline to learn about software engineering processes and how to do precisely that. Don’t have 6 months? Here’s the small version:

Divide the whole project into a set of major milestones
Break those milestones into features to make those milestones possible
Go deep into those features and learn what your client wants
Try to estimate those features in hours/days of work
If you have some experienced people nearby, ask them to make revisions in your estimations considering YOUR skill level

PLEASE, plan things out. A recent study found that projects that had requirements clear before development started were 97% more likely to succeed than those that didn’t.

After estimating the features, add some extra time for the chaos of the world, bugs, or revisions. This practice helps manage client expectations and ensures you have room to deliver high-quality work — this is the goal since this is what is going to propel your organic reach.

Remember: it's always better to under-promise and over-deliver. Not the other way around.

4. I made a tool to help: Founders Kit

Throughout the years of freelancing, I tried a bunch of different tools to help me actually organize my process. It took a lot of trial and error only to realize that no tool perfectly fit my needs — in some cases, they were too complex, bringing tons of functionalities that I didn’t use, in others, they didn’t have some essential stuff.

The great part of this is that I’m an engineer! So, throughout the past month, I worked hard to create a solution to help manage the business side of this. It’s called Founders Kit and I’d love it if you could help us on Product Hunt and check it out ;D

5. Conclusion

Hey! You made it to the end. I hope that you have started to realize how freelancing in software engineering can be a rewarding and challenging career path, which can earn you some extra money and grant you some really cool experiences.

By following the guidelines outlined in this guide - from finding and securing clients, to negotiating effectively, managing projects, and utilizing tools like Founders Kit - you'll be well-equipped to start your freelancing journey.

How To Add Auth With Lucia To Your React/Next.js App - A Step By Step Guide

Lucas Lima do Nascimento — Tue, 20 Aug 2024 12:11:19 +0000

Although authentication is one of the most common web app features, there are so many different ways to go about it, which makes it a very non-trivial task. In this post, I will share my personal experience using Lucia - a modern, framework-agnostic authentication library that has been getting, deservedly so, a lot of love from the community in recent months.

First, I will demonstrate how you can implement it within your Next.js application through a step-by-step guide you can follow. It will require a fair amount of code and configuration, but the process itself is quite straightforward.

Secondly, we’ll see how to achieve the same with Wasp in just a few lines of code. Wasp is a batteries-included, full-stack framework for React & Node.js that uses Lucia under the hood to implement authentication. It runs fully on your infrastructure and is 100% open-source and free.

Why Lucia?

When it comes to adding authentication to your applications, there are several popular solutions available. For instance, Clerk offers a paid service, while NextAuth.js is an open-source solution alongside Lucia, which has become quite popular recently.

These tools provide robust features, but committing to third-party services — which not only adds another layer of complexity but also have paid tiers you have to keep an eye on — might be an overkill for a small project. In-house solutions keep things centralized but leave it to a developer to implement some of the mentioned features.

In our case, Lucia has proved to be a perfect middle ground - it’s not a third-party service and does not require a dedicated infrastructure, but it also provides a very solid foundation that’s easy to build upon.

Now, let’s dive into a step-by-step guide on how to implement your own authentication with Next.js and Lucia.

Step 1: Setting up Next.js

First, create a new Next.js project:

npx create-next-app@latest my-nextjs-app
cd my-nextjs-app
npm install

Step 2: Install Lucia

Next, install Lucia:

npm install lucia

Step 3: Set up Authentication

Create an auth file in your project and add the necessary files for Lucia to be imported and initialized. It has a bunch of adapters for different databases, and you can check them all here. In this example, we’re going to use SQLite:

// lib/auth.ts
import { Lucia } from "lucia";
import { BetterSqlite3Adapter } from "@lucia-auth/adapter-sqlite";

const adapter = new BetterSQLite3Adapter(db); // your adapter

export const lucia = new Lucia(adapter, {
  sessionCookie: {
    // this sets cookies with super long expiration
    // since Next.js doesn't allow Lucia to extend cookie expiration when rendering pages
    expires: false,
    attributes: {
      // set to `true` when using HTTPS
      secure: process.env.NODE_ENV === "production"
    }
  }
});

// To get some good Typescript support, add this!
declare module "lucia" {
  interface Register {
    Lucia: typeof lucia;
  }
}

Step 4: Add User to DB

Let’s add a database file to contain our schemas for now:

// lib/db.ts
import sqlite from "better-sqlite3";

export const db = sqlite("main.db");

db.exec(`CREATE TABLE IF NOT EXISTS user (
    id TEXT NOT NULL PRIMARY KEY,
    github_id INTEGER UNIQUE,
    username TEXT NOT NULL
)`);

db.exec(`CREATE TABLE IF NOT EXISTS session (
    id TEXT NOT NULL PRIMARY KEY,
    expires_at INTEGER NOT NULL,
    user_id TEXT NOT NULL,
    FOREIGN KEY (user_id) REFERENCES user(id)
)`);

export interface DatabaseUser {
  id: string;
  username: string;
  github_id: number;
}

Step 5: Implement Login and Signup

To make this happen, we firstly have to create a GitHub OAuth app. This is relatively simple, you create it, add the necessary ENVs and callback URLs into your application and you’re good to go. You can follow GitHub docs to check how to do that.

//.env.local
GITHUB_CLIENT_ID=your-github-client-id
GITHUB_CLIENT_SECRET=your-github-client-secret

After that, it’s a matter of adding login and signup functionalities to your pages, so, let’s do that real quick:

// login/page.tsx
import { validateRequest } from "@/lib/auth";
import { redirect } from "next/navigation";

export default async function Page() {
  const { user } = await validateRequest();
  if (user) {
    return redirect("/");
  }
  return (
    <>
      <h1>Sign in</h1>
      <a href="/login/github">Sign in with GitHub</a>
    </>
  );
}

After adding the page, we also have to add the login redirect to GitHub and the callback that’s going to be called. Let’s first add the login redirect with the authorization URL:

// login/github/route.ts
import { generateState } from "arctic";
import { github } from "../../../lib/auth";
import { cookies } from "next/headers";

export async function GET(): Promise<Response> {
  const state = generateState();
  const url = await github.createAuthorizationURL(state);

  cookies().set("github_oauth_state", state, {
    path: "/",
    secure: process.env.NODE_ENV === "production",
    httpOnly: true,
    maxAge: 60 * 10,
    sameSite: "lax"
  });

  return Response.redirect(url);
}

And finally, the callback (which is what we actually add in GitHub OAuth):

// login/github/callback/route.ts
import { github, lucia } from "@/lib/auth";
import { db } from "@/lib/db";
import { cookies } from "next/headers";
import { OAuth2RequestError } from "arctic";
import { generateId } from "lucia";

import type { DatabaseUser } from "@/lib/db";

export async function GET(request: Request): Promise<Response> {
  const url = new URL(request.url);
  const code = url.searchParams.get("code");
  const state = url.searchParams.get("state");
  const storedState = cookies().get("github_oauth_state")?.value ?? null;
  if (!code || !state || !storedState || state !== storedState) {
    return new Response(null, {
      status: 400
    });
  }

  try {
    const tokens = await github.validateAuthorizationCode(code);
    const githubUserResponse = await fetch("https://api.github.com/user", {
      headers: {
        Authorization: `Bearer ${tokens.accessToken}`
      }
    });
    const githubUser: GitHubUser = await githubUserResponse.json();
    const existingUser = db.prepare("SELECT * FROM user WHERE github_id = ?").get(githubUser.id) as
      | DatabaseUser
      | undefined;

    if (existingUser) {
      const session = await lucia.createSession(existingUser.id, {});
      const sessionCookie = lucia.createSessionCookie(session.id);
      cookies().set(sessionCookie.name, sessionCookie.value, sessionCookie.attributes);
      return new Response(null, {
        status: 302,
        headers: {
          Location: "/"
        }
      });
    }

    const userId = generateId(15);
    db.prepare("INSERT INTO user (id, github_id, username) VALUES (?, ?, ?)").run(
      userId,
      githubUser.id,
      githubUser.login
    );
    const session = await lucia.createSession(userId, {});
    const sessionCookie = lucia.createSessionCookie(session.id);
    cookies().set(sessionCookie.name, sessionCookie.value, sessionCookie.attributes);
    return new Response(null, {
      status: 302,
      headers: {
        Location: "/"
      }
    });
  } catch (e) {
    if (e instanceof OAuth2RequestError && e.message === "bad_verification_code") {
      // invalid code
      return new Response(null, {
        status: 400
      });
    }
    return new Response(null, {
      status: 500
    });
  }
}

interface GitHubUser {
  id: string;
  login: string;
}

Other important thing here is that, now, we’re going with GitHub OAuth, but, generally, these libraries contain a bunch of different login providers (including simple username and password), so it’s usually just a pick and choose if you want to add other providers.

// lib/auth.ts
import { Lucia } from "lucia";
import { BetterSqlite3Adapter } from "@lucia-auth/adapter-sqlite";
import { db } from "./db";
import { cookies } from "next/headers";
import { cache } from "react";
import { GitHub } from "arctic";

import type { Session, User } from "lucia";
import type { DatabaseUser } from "./db";

// these two lines here might be important if you have node.js 18 or lower. 
// you can check Lucia's documentation in more detail if that's the case 
// (https://lucia-auth.com/getting-started/nextjs-app#polyfill)
// import { webcrypto } from "crypto";
// globalThis.crypto = webcrypto as Crypto;

const adapter = new BetterSqlite3Adapter(db, {
  user: "user",
  session: "session"
});

export const lucia = new Lucia(adapter, {
  sessionCookie: {
    attributes: {
      secure: process.env.NODE_ENV === "production"
    }
  },
  getUserAttributes: (attributes) => {
    return {
      githubId: attributes.github_id,
      username: attributes.username
    };
  }
});

declare module "lucia" {
  interface Register {
    Lucia: typeof lucia;
    DatabaseUserAttributes: Omit<DatabaseUser, "id">;
  }
}

export const validateRequest = cache(
  async (): Promise<{ user: User; session: Session } | { user: null; session: null }> => {
    const sessionId = cookies().get(lucia.sessionCookieName)?.value ?? null;
    if (!sessionId) {
      return {
        user: null,
        session: null
      };
    }

    const result = await lucia.validateSession(sessionId);
    // next.js throws when you attempt to set cookie when rendering page
    try {
      if (result.session && result.session.fresh) {
        const sessionCookie = lucia.createSessionCookie(result.session.id);
        cookies().set(sessionCookie.name, sessionCookie.value, sessionCookie.attributes);
      }
      if (!result.session) {
        const sessionCookie = lucia.createBlankSessionCookie();
        cookies().set(sessionCookie.name, sessionCookie.value, sessionCookie.attributes);
      }
    } catch {}
    return result;
  }
);

export const github = new GitHub(process.env.GITHUB_CLIENT_ID!, process.env.GITHUB_CLIENT_SECRET!);

Step 6: Protect Routes

After adding all that stuff to make the login properly work, we just have to ensure that routes are protected by checking authentication status — in this case, this is a simple page that shows username, id and a button in case signed in, and redirects to /login, where the user will complete the login above through a form.

import { lucia, validateRequest } from "@/lib/auth";
import { redirect } from "next/navigation";
import { cookies } from "next/headers";

export default async function Page() {
  const { user } = await validateRequest();
  if (!user) {
    return redirect("/login");
  }
  return (
    <>
      <h1>Hi, {user.username}!</h1>
      <p>Your user ID is {user.id}.</p>
      <form action={logout}>
        <button>Sign out</button>
      </form>
    </>
  );
}

async function logout(): Promise<ActionResult> {
  "use server";
  const { session } = await validateRequest();
  if (!session) {
    return {
      error: "Unauthorized"
    };
  }

  await lucia.invalidateSession(session.id);

  const sessionCookie = lucia.createBlankSessionCookie();
  cookies().set(sessionCookie.name, sessionCookie.value, sessionCookie.attributes);
  return redirect("/login");
}

interface ActionResult {
  error: string | null;
}

Piece of cake, isn’t it? Well, not really.

Let’s recap which steps were necessary to actually make this happen:

Set up your app.
Add Lucia.
Set up authentication.
Add User to DB.
Obtain GitHub OAuth credentials and configure your environment variables.
Create some util functions.
Add Login and Sign up routes, with custom made components.
Finally, create a protected route.

Honestly, when trying to create something cool FAST, repeating these steps and debugging a few logical problems here and there that always occur can feel a little bit frustrating. Soon, we’ll take a look at Wasp’s approach to solving that same problem and we’ll be able to compare how much easier Wasp’s auth implementation process is.

In case you want to check the whole code for this part, Lucia has an example repo (that is the source of most of the code shown), so, you can check it out if you’d like.

Wasp Implementation

Now, let’s go through how we can achieve the same things with Wasp 🐝. Although it still uses Lucia in the background, Wasp takes care of all the heavy-lifting for you, making the process much quicker and simpler. Let’s check out the developer experience for ourselves.

Before we just into it, in case you’re more of a visual learner, here’s a 1-minute video showcasing auth with Wasp.

As seen in the video, Wasp is a framework for building apps with the benefits of using a configuration file to make development easier. It handles many repetitive tasks, allowing you to focus on creating unique features. In this tutorial, we’ll also learn more about the Wasp config file and see how it makes setting up authentication simpler.

Step 1: Create a Wasp Project

curl -sSL https://get.wasp-lang.dev/installer.sh | sh
wasp new my-wasp-app
cd my-wasp-app

Step 2: Add the User entity into our DB

As simple as defining the app.auth.userEntity entity in the schema.prisma file and running some migrations:

model User {
  id Int @id @default(autoincrement())
  email   String   @unique
  name    String?
  // Add your own fields below
  // ...
}

Step 3: Define Authentication

In your main Wasp configuration, add the authentication provider you want for your app

//main.wasp
app myApp {
  wasp: {
    version: "^0.14.0"
  },
  title: "My App",
  auth: {
    userEntity: User,
    methods: {
      // 2. Enable Github Auth
      gitHub: {}
    },
    onAuthFailedRedirectTo: "/login"
  },
}

And after that, just run in your terminal:

wasp db migrate-dev

Step 4: Get your GitHub OAuth credentials and app running

This part is similar for both frameworks, you can follow the documentation GitHub provides here to do so: Creating an OAuth app - GitHub Docs. For wasp app, the callback urls are:

While developing: http://localhost:3001/auth/github/callback
After deploying: https://your-server-url.com/auth/github/callback

After that, get your secrets and add it to the env file:

//.env.server
GITHUB_CLIENT_ID=your-github-client-id
GITHUB_CLIENT_SECRET=your-github-client-secret

Step 5: Add the routes and pages

Now, let’s simply add some routing and the page necessary for login — the process is way easier since Wasp has pre-built Login and Signup Forms, we can simply add those directly:

// main.wasp

route SignupRoute { path: "/signup", to: SignupPage }
page SignupPage {
  component: import { SignupPage } from "@src/SignupPage"
}

route LoginRoute { path: "/login", to: LoginPage }
page LoginPage {
  component: import { LoginPage } from "@src/LoginPage"
}

// src/LoginPage.jsx
import { Link } from 'react-router-dom'
import { LoginForm } from 'wasp/client/auth'

export const LoginPage = () => {
  return (
    <div style={{ maxWidth: '400px', margin: '0 auto' }}>
      <LoginForm />
      <br />
      <span>
        I don't have an account yet (<Link to="/signup">go to signup</Link>).
      </span>
    </div>
  )
}

// src/SignupPage.jsx
import { Link } from 'react-router-dom'
import { SignupForm } from 'wasp/client/auth'

export const SignupPage = () => {
  return (
    <div style={{ maxWidth: '400px', margin: '0 auto' }}>
      <SignupForm />
      <br />
      <span>
        I already have an account (<Link to="/login">go to login</Link>).
      </span>
    </div>
  )
}

And finally, for protecting routes, is as simple as changing it in main.wasp adding authRequired: true , so, we can simply add it like this:

// main.wasp
page MainPage {
  component: import Main from "@src/pages/Main",
  authRequired: true
}

If you’d like to check this example in more depth, feel free to check this repo here: wasp/examples/todo-typescript at release · wasp-lang/wasp (github.com).
Other great place to check is their documentation, which can be found here. It covers most of what I said here, and even more (e.g. the awesome new hooks that came with Wasp v0.14)

Way easier, isn’t it? Let’s review the steps we took to get here:

Set up the project.
Add the User entity to the database.
Define authentication in the main Wasp configuration.
Obtain GitHub OAuth credentials and configure your environment variables.
Add routes and pages for login and signup with pre-built, easy-to-use components.
Protect routes by specifying authRequired in your configuration.

Customizing Wasp Auth

If you need more control and customization over the authentication flow, Wasp provides Auth hooks that allow you to tailor the experience to your app's specific needs. These hooks enable you to execute custom code during various stages of the authentication process, ensuring that you can implement any required custom behavior.

For more detailed information on using Auth hooks with Wasp, visit the Wasp documentation.

Bonus Section: Adding Email/Password Login with Wasp and Customizing Auth

Now let’s imagine we want to add email and password authentication — with all the usual features we’d expect that would follow this login method (e.g. reset password, email verification, etc.).

With Wasp, all we have to do is add a few lines to your main.wasp file, so, simply updating your Wasp configuration to include email/password authentication makes it work straight out of the box!

Wasp will handle the rest, also updating UI components and ensuring a smooth and secure authentication flow.

//main.wasp
app myApp {
  wasp: {
    version: "^0.14.0"
  },
  title: "My App",
  auth: {
    // 1. Specify the User entity
    userEntity: User,
    methods: {
      // 2. Enable Github Auth
      gitHub: {},
      email: {
        // 3. Specify the email from field
        fromField: {
          name: "My App Postman",
          email: "hello@itsme.com"
        },
        // 4. Specify the email verification and password reset options
        emailVerification: {
          clientRoute: EmailVerificationRoute, //this route/page should be created
        },
        passwordReset: {
          clientRoute: PasswordResetRoute, //this route/page should be created
        },
        // Add an emailSender -- Dummy just logs to console for dev purposes
        // but there are a ton of supported providers :D
        emailSender: {
          provider: Dummy,
        },
      },
    },
    onAuthFailedRedirectTo: "/login"
  },
}

Implementing this in Next.js with Lucia would take a lot more work, involving a bunch of different stuff from actually sending the emails, to generating the verification tokens and more. They reference this here, but again, Wasp’s Auth makes the whole process way easier, handling a bunch of the complexity for us while also giving a bunch of other UI components, ready to use, to ease the UI details (e.g. VerifyEmailForm, ForgotPasswordForm and, ResetPasswordForm).

The whole point here is the difference in time and developer experience in order to implement the same scenarios. For the Next.js project with Lucia, you will spend at least a few hours implementing everything if you’re going all by yourself. That same experience translates to no more than 1 hour with Wasp. What to do with the rest of the time? Implement the important stuff your particular business requires!

Can you show us your support?

Are you interested in more content like this? Sign up for our newsletter and give us a star on GitHub! We need your support to keep pushing our projects forward 😀

Conclusion

I think that if you’re a developer who wants to get things done, you probably noted the significant difference in complexity levels of both of those implementations.

By reducing boilerplate and abstracting repetitive tasks, Wasp allows developers to focus more on building unique features rather than getting bogged down by authentication details. This can be especially beneficial for small teams or individual developers aiming to launch products quickly.

Of course, generally when we talk abstractions, it always comes with the downside of losing the finesse of a more personal implementation. In this case, Wasp provides a bunch of stuff for you to implement around and uses Lucia on the background, so the scenario where there’s a mismatch of content implementation is highly unlikable to happen.

In summary, while implementing your own authentication with Next.js and Lucia provides complete control and customization, it can be complex and time-consuming. On the other hand, using a solution like Wasp simplifies the process, reduces code length, and speeds up development.

7 Steps To Become A Prompt Engineer

Lucas Lima do Nascimento — Wed, 14 Aug 2024 09:40:42 +0000

Introduction

Hello there, dear reader! If you’re looking for an article where you’ll actually find a DOABLE guide for getting somewhere with prompt engineering, you’ve come to the right place!

My name is Lucas and I’ve been a software engineer for over 5 years now.

My journey into the world of software and AI began during my university studies at UFU (Universidade Federal de Uberlândia), where I pursued a Bachelor's Degree in Computer Engineering and actually took part in a Robotics Team called Roboforge — you should probably know that robotics and AI are kind of close fields too — where we actually got first place while competing in one of Latin America’s biggest competition: LARC (which stands for Latin America Robotics Competition, not that creative, I have to say).

Literally me, programming at the competition

Some really awesome robots that were playing soccer there (fully autonomous)

And in this guide, I’ll give my best shot at taking you step-by-step through what you should learn to get a position as a prompt engineer!

Step 1: Understanding the Basics of LLMs

Before diving into prompt engineering in particular, it's important to have a solid foundation in AI. You know it already — first, you have to learn to walk before you learn to run.

So, explore a little bit and understand how LLMs work. You don’t have to know everything, though, but, try to answer at least 3 questions:

What the hell is an LLM?
What types of LLM exist out there?
How do I build an LLM? (You don’t have to build one! Just learn the basics on how it’s done)

Answering these 3 questions above, you’ll probably find yourself with a bunch of new terms added to your vocabulary and, even more than that, with a bunch of new knowledge added to your toolkit.

It also can be motivating to actually see the requirements of a few prompt engineering positions and Latitude has created a platform for you to see those positions easily. You can check that out here:

⭐️ Prompt Engineering Jobs by Latitude ⭐️

Step 2: Learn by Doing: Craft a few prompts

Crafting prompts is an iterative process that involves trial and error. Start by experimenting with simple prompts for personal projects and use cases while gradually moving on to more complex ones. This hands-on approach — which we usually call project-based learning, a really interesting way to learn, which usually leads to ~23% increase in student achievement — will help you understand how AI models interpret and respond to different inputs

No ideas on how to start prompting? No worries, I’ve got you covered! Let’s check a few examples:

Hop on your favorite LLM (and if you don’t have one, feel free to check our comparison guide) and start with a few basic prompts:

Long article text here .............
....................................

Summarize the above article for me.

Or, another useful example:

Interesting topic title you found somewhere

Translate the above topic title to French.

Both of those examples can show how simple and powerful prompt engineering can really be! Feel free to try those out or any others that might suit you.

Step 3: Learn Some Programming Basics

Programming is a critical skill for any AI professional. To become a proficient prompt engineer, you should learn at least the basics of one programming language such as Python or R, that are really relevant to the field.

Besides that, there are numerous benefits that coding skills will give you: from implementing and testing your prompts programmatically to manipulating data effectively. There are numerous online resources and courses available to help you get started with programming (e.g. Python Roadmap — an awesome roadmap to guide you through your journey, or Python Project Ideas for you to learn by doing).

Step 4: Applying prompt engineering to real-world examples

Awesome, so, now, you already know how to create basic prompts and how to code a little. A really good next step would probably be to start checking some real-world scenarios and how they are being handled while retaining information about the users too!

Let’s check one example here as well:

Start by imaging a scenario where the company you’re working for has an e-commerce application.
They’re implementing a new search mechanism with AI in order that users can search with natural language
The AI here should return a JSON with the characteristics the user asked for

If you’re running an e-commerce for clothing, you’ll probably want to search for relevant information to that sector — like the age, in years. For example:

# If the user says:
# Birthday gift for my 18 months old daughter

# Maybe a good return would be:
{
  "gender": "female",
  "occasion": "birthday",
  "age_years": 1.5
}

Now, let’s run this same scenario working for an e-commerce for sports clothing. Now, searching for the same elements might not be adequate.

# If the user says:
# Birthday gift for my 10 years old daughter, she loves skateboarding

# Maybe a better return would be:
{
  "gender": "female",
  "occasion": "birthday",
  "sport_suggestion": "skate",
  "age_years": 10
}

While creating software, the user is always the most important role in the play — from e-commerces to emails, to study companions and code assistants. He is the one who actually pays you, so, always remember to keep that in mind while studying other real-world scenarios.

Step 5: Learn where things go wrong

If you got here, you probably faced a few problems here and there while playing with prompting. From math to sources, to hallucination, there are literally tons of different pitfalls you can end up into if you’re not carefully creating your prompt.

This step here is actually learned by failing, and then, learning (based on how inaccurate the result was) what you can do differently to improve your prompt.

Want source citations and your LLM is generating people and articles on the fly? Try RAG (Retrieval Augmented Generation — that you can learn more about here — and LLMs with access to the internet! They will surely be more precise.

Some really bizarre math is showing up mid-calculation? Honestly, LLMs kind of suck at math (which I, personally, find ironically funny). Maybe you can try out some different LLMs — with more focus on the math side — or a different approach to solving the same problem, running things step-by-step or skipping calculations with LLMs and using general programming to solve that instead.

Step 6: Get Some Fine-Tuning Skills and Improve Reliability

Ok. At this point, you probably know your way around prompting for most of the scenarios you’ll find out there. Unfortunately, as you’ll eventually realize, LLMs tend to be extremely chaotic when not fine-tuned properly, creating varying degrees of “creativity” in your responses.

This could not be a problem, but, generally, it is. Whenever you’re working with responses, we generally want the AI to have a limited range of variance and bias so that we can constrain our answers between the confinement of accepted answers.

If you’re in this step, I recommend you take a look at how LLMs are actually configured, check out temperature and Top P sampling, and check for yourself how changing those values and percentages can alter the variance obtained for your prompts.

Ready to build, test, and deploy some of those prompts? A really cool platform for this is Latitude’s new product, which is currently in early access! Whenever it’s released, I’m sure you’ll find a bunch of cool stuff there that will actually help you in your journey, so check it out!

⭐️ Enter the Waitlist! ⭐️

Step 7: Showcase your work and Start Applying

Hands-on experience is invaluable in the field of prompt engineering and hey, if you’re following along, I’m sure you have tons of that, so, it’s just the time to showcase it to the world!

Don’t forget to make your work tangible to HR persons! They are the ones recruiting and looking for people, so, show both scenarios: technical for the technical people and non-technical for the non-technical people — this means basically: including a variety of prompts and the corresponding AI responses to demonstrate your expertise, translating that response to non-technical terms when needed.

Once you have a solid way to showcase things -- being that from just posts or a portfolio, start applying for prompt engineering positions and it’s just a matter of waiting until you find an awesome place to work.

Kind of lost on where to apply? Latitude’s come to the rescue again — yes, they truly built a whole platform for you to check prompt engineering jobs out, so please, take a look:
⭐️ Prompt Engineering Jobs by Latitude ⭐️

Conclusion

Hey! I’m glad that you got here!

Becoming an engineer is a rewarding journey that involves mastering fundamentals, honing your skills, understanding user needs, and crafting effective products — and this goes for any engineering, from software to prompting.

If you follow those steps, you'll be REALLY well-equipped to enter this exciting field and honestly, we'd love to hear your thoughts and experiences as you embark on this path. Feel free to share your insights in the comments below and don't forget to check out Latitude's new product to further enhance your skills!

Creating a personal brand: How to sell yourself as a developer

Lucas Lima do Nascimento — Tue, 06 Aug 2024 07:01:00 +0000

Everything changes so fast these days that, standing out as a developer is more important than ever. As much as your technical skills matter, in this sea of programmers, it's your personal touch that can truly set you apart.

But how can you create your personal brand? How to apply your personal brand to your presentations and public persona? In this article, we'll walk you through the process of creating a personal brand, showcasing yourself to the public, and leaving a long-lasting mark in the developer community.

So, what’s branding actually?

Branding, in the context of personal branding, is all about creating a unique identity that encapsulates your skills, experiences, and values. It's how you present yourself to the world. It doesn’t always need to be related to you as a person though — there are numerous branding guides for companies and how they present themselves too!

When it comes to personal branding, consistency is essential. Your brand should be an authentic representation of who you are, and it should remain consistent across different platforms and interactions. This means that the way you present yourself in your portfolio, on your social media platforms, and in person should all align with your personal brand. Besides that, your brand is not just about how you present yourself, but also how others perceive you. This includes the quality of your work, your work ethic, your communication style, and even your personality traits.

Now, let me show you an example of how I sell my image, and let’s start breaking down everything you need to know on how to do it too!

First of all, the theme

Here’s a GIF of my portfolio (and you can find it here in case you want to check it for yourself). So, first of all, let’s see if we can spot a clear theme:

The bright contrast in the colors, the 8-bit font, the big buttons, writing animations, and a simple avatar image. The theme is clear: Games!

Besides that, the first initial phrase “Welcome adventurer” is a classical phrase for a specific genre of games: RPG/Medieval Games!

Great! Now, why did I choose this theme? Randomly? When the user checks the about me section, he’ll discover:

So there we go! The theme is not only consistent on all the UI, but it also contains a fragment of my personality — being a tabletop RPG Dungeon Master — on it. Defining a theme for yourself can be hard, but, starting to think about the hobbies and things that you enjoy in your personal life can give a great personal touch to your brand!

Building Your Personal Brand

Now that we have a clear understanding of what personal branding is, let's move on to the next step - building your personal brand. This process involves identifying your unique strengths and skills, defining your target audience, and finally, crafting your brand.

Identifying Your Unique Strengths and Skills

To begin with, it’s a good idea to try to identify what makes you unique as a developer. A helpful tool for this is a SWOT matrix, where you list your Strengths, Weaknesses, Opportunities, and Threats. Strengths could be your technical abilities or soft skills like communication and other ways you approach problems on a day-to-day basis. Weaknesses are areas where you could improve. Opportunities could be networking, open-source contributions, or learning new technologies and Threats could be things like a highly competitive job market or the rapid pace of technological change.

Defining Your Target Audience

Next, you need to define who your target audience is. These are the people you want to reach with your personal brand - potential employers, colleagues, or the broader developer community. Having a clear understanding of your target audience will help you tailor your brand to appeal to them. In the case of my portfolio, for example, it’s clearly tailored to potential employers!

Crafting Your Personal Brand

Once you've identified your strengths and skills and defined your target audience, you can begin crafting your personal brand. This involves deciding on a consistent image or theme (like the game theme I showed above) and communicating your values and skills.

This is also usable in the context of new brands and ideas! For example, at Webcrumbs — a great OSS plugin system, that can really streamline your development process — they started from zero and have now reached a point where the brand stands on solid ground with colors, icons, and themes that certainly cuts an impression (and even more than that, makes them memorable)!

Showcasing Yourself to the Public

Having crafted your personal brand, the next step is to showcase it to the public. This involves creating an online presence that aligns with your brand. Honestly, this can be achieved in a bunch of different ways: e.g. building a portfolio website that highlights your work and skills, or even leveraging social media platforms and GitHub to reach a wider audience.

Just make sure that, whenever you’re using a brand as a communication focus, keep the same communication tone and other aspects throughout different platforms. If you’re funny and casual everywhere, it’s not because you’re on LinkedIn that you’re not going to be casual anymore. Retain some professionalism (which is LinkedIn’s case in the general tone that exists there), but try to be as much casual as you’d be in your portfolio communications.

Looking for a showcase example?

We’re actually launching a new product here at Webcrumbs: FrontendAI! An awesome code generator for your front-end UI!
It takes you from prompt to product in seconds and it would be awesome if you could check it out! It’s totally free and can really speed things up in your development process!

🚀 Check FrontendAI at Product Hunt 🚀

Leaving a Mark in the Developer Community

There are other forms that you can create a personal brand, and, one of the bigger ones is leaving a mark in our community. This can be achieved through a variety of different ways, from networking to contributing to open-source projects, and even just sharing your knowledge with others! All those ideas present an opportunity for you to showcase your work and skills, and even more than that, your personal self to others.

Networking and Building Connections

Networking is a crucial part of building your brand. Try to attend industry events, join online forums/Reddit, and participate in developer communities. Introduce yourself, share your work, and engage with others. Building genuine relationships can help you establish a strong reputation and open up new opportunities — to be honest with you, a bunch of different projects I’ve participated in became opportunities just because I had good connections, formed throughout the daily work with the people making it, so, I can’t stress enough how important this is!

Contributing to Open-Source Projects

Another really cool way to create your brand is to contribute to open-source projects. It is a great way to showcase your skills and give back to the community on things you enjoy while also providing an excellent opportunity to collaborate with other developers and learn from them.

Your contributions can serve as a testament to your expertise and dedication, enhancing your brand and serving as proof of trust about the quality of your work — a few positions even ask for your personal contributions while in the interview.

Here at Webcrumbs, we’re actually Open-Source, so if you’re looking somewhere to start contributing to and you’re looking for places that you can have a lot of impact, feel free to star us and check our issues! Also, in case you haven't checked out the launch, here's a quick link for it:

Frontend AI - Your UI generated from prompts or images | Product Hunt

Want to speed up your frontend? Meet Frontend AI. Simply write what you want or paste an image, preview your component and get your code. Try it out—no login required! 🧙 Tips: Try it with their suggested prompts or an image from Figma or your favorite app.

producthunt.com

Sharing Knowledge Through Blogging and Journaling

Sharing your knowledge through blogging or vlogging can position you as a thought leader in your field. Write about your experiences, share tutorials, or discuss industry trends. This not only helps others but also reinforces your expertise and passion for your work. Consistently producing quality content can significantly boost your personal brand.

This was part of the reason I’ve actually begun to write here. After receiving some great feedback at work, I started to think of ways that I could share my knowledge with other people and show a few opinions and takes I had in software engineering. I can’t recommend enough how journaling your journey can impact your life — it’s a really powerful and yet simple habit.

Conclusion

In summary, creating a personal brand as a developer is a multifaceted process that involves identifying your unique strengths, defining your target audience, and showcasing your skills and personality through various platforms. By building a consistent and authentic brand, you can stand out in the competitive tech industry and leave a lasting impression in the developer community.

Don't forget to network, contribute to open-source projects, and share your knowledge to further solidify your brand. We'd love to hear your thoughts and experiences on personal branding, so feel free to leave a comment below. Also, be sure to check out WebCrumbs for some exciting tools and opportunities to contribute to open-source projects!

The Ultimate LLM Leaderboard: Ranking the Best Language Models

Lucas Lima do Nascimento — Wed, 24 Jul 2024 12:30:00 +0000

Introduction

You’re there, casually scrolling your timeline as a subtle vibration from your phone catches your attention. Another AI LLM is reaching the market and is the new best toy in town that everyone should check.

The first time that happened, you were probably actually intrigued and maybe even went to check it out, but, by the fourth and even fifth time, checking new LLMs and AIs started to become a little tiring.

Want to check which are the best LLMs for each case (API, personal use/prompting, etc), ranked, without having to spend hours searching and comparing each one? This article is for you, then.

Criteria for Ranking

The ranking of language models in this leaderboard is based on a list of criteria made by me, designed to evaluate their overall performance and applicability. These criteria include:

Overview: A small resume about who is the creator of the LLM (and maybe even some polemics you should learn about)
Strengths: Where and in which cases the LLM excels at
Cost: The model's capacity to handle increasing amounts of data and user interactions along with how much would that cost you. Generally, this uses tokens for measurement. Not sure what a token is and how it’s calculated? You can consider it equal to ~4 characters of text for common English.
Ease of Integration/Community Support: How easily the model can be integrated into existing systems and workflows and the availability of resources, documentation, and community engagement to assist us with implementation and usage.

LLM Setup - The quick and easy route

HOLD FAST! Before we continue, if you’d prefer to learn by doing and using those powerful LLMs we have something exciting for you!

Join our waitlist for early access to Latitude’s new platform. It's designed to help LLM developers streamline their work and bring ideas to life with confidence, helping a ton in the measurement process I mentioned above.

We're honestly truly excited about this platform and can't wait to see what you create with it!

Don't miss out! Click the link below to join our waitlist 🚀

⭐️ Enter the Waitlist! ⭐️

Top Language Models

Now, let’s jump right into the LLMs that are most famous today. Of course, I wouldn’t be able to actually review every single one (there are literally thousands of models out there) but, here we’ll check: GPT, Gemini, LLaMA, Claude, and Copilot.

GPT

Overview: GPT (Generative Pre-trained Transformer) is one of the most well-known language models developed by OpenAI. It has a ton of models: 3.5-turbo, 4, 4o (the most recent), and more. In terms of polemics, it’s involved in kind a few of them (e.g. ChatGPT's voice closely resembles Scarlett Johnasson's, says lab analysis : NPR), so, you can also take that into consideration.

Strengths: Exceptional accuracy and versatility in generating human-like text. It has some great API documentation and integration also, while still maintaining a good interface for human interaction.

Prices: Varies depending on usage and subscription plans, the better trained the model, the more expensive it becomes, ranging from $0.5/1M tokens to $5/1M tokens on the most recent model. You can check them all here: Pricing | OpenAI

Looking for image models? It also has, with prices ranging from $0.016/image to $0.040/image. If you’re interested in using it for prompting and normal use instead of integration, it has both a free plan and a Plus plan with different models, image generation, and a price of $20/month.

Gemini

Overview: Gemini is a robust language model known for its efficiency and scalability. It’s made by Google and recently had some really awesome announcements at I/O (a conference made by Google to showcase new stuff). It’s also mentioned in a few polemics (e.g Google pauses Gemini's AI image generation after diversity controversies) that you can take into consideration.

Strengths: Amazing context window (this basically means it can use more data as the font of a single response), great language proficiency too!

Prices: For APIs, pricing based on usage too, having a free tier with low requests number and $0.35 / million tokens, later on. For personal use, Gemini Code Assist, for example, costs $19 per user, per month.

LLaMA

Overview: LLaMA (Large Language Model Meta AI) is designed to be less resource-intensive than other models, it has a different license scheme, which means that this resembles “something open source” and as the other ones, also has a few polemics in its name (e.g. Meta Stops Disclosing the Data It Uses to Train AI Models Like Llama 2 - Business Insider).

Strengths: They try to follow guidelines for responsible AI creation and innovation. It also has different models specific for different scenarios like Code LLaMA, for code generation, for example. It’s great for research and English-focused applications.

Prices: Basically free while using Meta AI or downloading and running it locally/self-host. You can also check out services for using as API, that for example can generate API keys for using LLaMA.

Claude

Overview: Claude is a versatile language model that excels in understanding and generating natural language. It’s a really interesting alternative to GPT, honestly — and, for the first time, I couldn’t find some polemics including it.

Strengths: Seems to perform better than GPT mostly regarding speed and prices, but tries to reach the same strengths, like conversational AI, etc.

Prices: For personal use, it starts out free and grows up to $20 for pro or $30 for teams. For APIs, costs $3/M tokens for input and $15 for output on their most intelligent model to date.

Copilot

Overview: Microsoft Copilot (here, I’ll evaluate both Copilot for Microsoft 365 and GitHub Copilot) and, although this one is not necessarily an LLM, it’s been publicly known that Microsoft is developing an in-house AI LLM — that is probably going to be connected to these products in the future, and, since Windows is used by a ton of people, I’ll also leave my review of them here. And let’s not forget some polemics here too (e.g. Controversial Microsoft AI screenshot feature delayed over security concerns | Science & Tech News | Sky News)

Strengths: Aims to be the best in aiding people on the daily life, from help with emails, to Excel, to code with GitHub Copilot’s suggestions and autocomplete. The strong side here is obviously if you/your company use Microsoft’s services. Outlook, Excel, Word, Teams, and all other products can benefit from here.

Prices: You'll actually find a really cool free tier here for consumption (prompting and images , but not code). But, if you want more of that uniqueness of integrating all Microsoft's products with AI, it's a subscription-based model with various tiers. You can check them all here: GitHub Copilot · Your AI pair programmer and here. Honestly, they both seem kind of expensive with GitHub Copilot seeming a little bit less, but, in company terms, they’re probably not that expensive.

Conclusion

Awesome! So, I hope that throughout this article I provided an in-depth look at the top language models, highlighting their strengths, pricing, polemics, and use cases. With Latitude's tools and insights, developers have the resources they need to choose the best LLM for their projects and optimize their performance, so, make sure to join the waitlist!

We encourage you to explore these models further and take advantage of Latitude's platform to enhance your development process. Don't forget to share your thoughts and experiences in the comments, and join the Latitude community to stay updated on the latest advancements in AI and LLMs.

For Engineers in a Hurry: A Guide for Implementing Security

Lucas Lima do Nascimento — Tue, 25 Jun 2024 13:07:53 +0000

Introduction

I’m sure that, when trying to be a solopreneur or create your own side projects, time constraints can be a big problem. Most of the time, we have to overlook things and do them as quickly as possible to meet the deadlines.

Unfortunately, security is one of those things that takes a lot of time to properly solve (if you work in the corporate world, you’ll actually get used to typically having entire teams dedicated to security and risk analysis) and, if we ignore it, consequences can be severe.

In this tutorial, we'll quickly implement robust security measures to protect one of my side projects from attackers and spammers with just a few lines of code!

Project introduction and solution

So, just a quick context: I’m creating a website called RulesLawyerAI. The project itself is kind of simple: A GPT wrapper trained on open rules and game aspects for tabletop rpgs. Whenever a user has a doubt, the user can simply ask the AI for the solution and it’ll be as precise as it possibly can. Here’s a 1-minute demo for it:

As you may have recently heard, most hosting and serverless services, which are designed to scale infinitely, can end up costing a lot if proper security measures are not in place. Besides that, data breaches and leaks are more frequent than ever, and, creating an idea without security is a true recipe for disaster. This means that even these small side-projects made for fun or learning can cost a bunch of money if we do not implement anything security-related.

That's precisely where Arcjet comes in. From bot and spam protection to rate limiting and email validation, Arcjet offers a robust set of tools to secure your Next.js (and Node, Bun, SvelteKit, Express, and Hono, with other common frameworks coming soon) application.

It's designed to be easy to integrate into your application, providing robust security measures with minimal effort on your part, exactly what I was looking for while working on this side project.

Disclaimer

Although Arcjet invited me to alpha test their product and write about the experience, they did not influence my opinion in this article. While they did provide the necessary support when I had questions about how things worked and how to implement things for this article, their discord channel is an official support channel, so I hope this level of support is standard for everyone who reaches out, as it appears to be the case for past cases.

Integration and Demonstration of the Security Improvements

Integrating Arcjet into your Next.js app is truly a straightforward process. The project I've been working on, RulesLawyerAI, utilizes Supabase for login. With Arcjet, it's relatively easy to add login spam prevention and limit the number of requests. Let's go through the process step-by-step.

First of all, if you’d like to check Arcjet’s documentation, you can find it here.

Let’s start by simply downloading the package to our codebase. In my case, I use pnpm, so:

pnpm add @arcjet/next

After installing the package, we should head up and create an account. Currently, since Arcjet is in beta, they are offering their protections and services totally free!

After creating an account, we’ll get an ARCJET_KEY, which we’ll use to connect our app to their platform:

After having the basic info set up, we should choose the things we actually want protected in our app. In my case, rate limiting and bot protection are must-haves, so that’s where we are going next!

So, for the rate-limiting:

import arcjet, { tokenBucket } from "@arcjet/next";
import { NextResponse } from "next/server";

const aj = arcjet({
  key: process.env.ARCJET_KEY!,
  rules: [
    // Create a token bucket rate limit. Other algorithms are supported.
    tokenBucket({
      mode: "LIVE", // will block requests. Use "DRY_RUN" to log only
      characteristics: ["ip.src"], // track requests by a custom user ID
      refillRate: 5, // refill 5 tokens per interval
      interval: 10, // refill every 10 seconds
      capacity: 10, // bucket maximum capacity of 10 tokens
    }),
  ],
});

This will create a token bucket rate limiter. It’s a really interesting algorithm for requests where basically, we have a bucket that refills itself for some tokens per interval, and, with each request, we deplete the bucket with a few tokens. You can learn more about the algorithm (and other types of rate-limiting algorithms here).

After adding the Arcjet instance, we just call it in our function to know if the request is approved or not:

export async function GET(req: Request) {
  const decision = await aj.protect(req, { requested: 5 }); // Deduct 5 tokens from the bucket

  if (decision.isDenied()) {
    return NextResponse.json(
      { error: "Too Many Requests", reason: decision.reason },
      { status: 429 },
    );
  }

  return NextResponse.json({ message: "Hello world" });
}

With this new code in place, we can check that on Arcjet’s website that, after we made sufficient requests to not afford to do another one, this happens:

And of course, on our application, we can make a more user-friendly message:

For the bot protection, just a simple middleware should do the trick. In Next.js, just creating a middleware.ts file at the root of the project solves this:

import arcjet, { createMiddleware, detectBot } from "@arcjet/next";
export const config = {
  // matcher tells Next.js which routes to run the middleware on.
  // This runs the middleware on all routes except for static assets.
  matcher: ["/((?!_next/static|_next/image|favicon.ico).*)"],
};
const aj = arcjet({
  key: process.env.ARCJET_KEY!,
  rules: [
    detectBot({
      mode: "LIVE", // will block requests. Use "DRY_RUN" to log only
      block: ["AUTOMATED"], // blocks all automated clients
    }),
  ],
});
// Pass any existing middleware with the optional existingMiddleware prop
export default createMiddleware(aj);

This will result in requests coming from bots being blocked! How cool is that?

Remember, security is a continuous process, not a one-time event. Always be vigilant for new threats and adjust your security measures accordingly. An excellent resource to keep in mind is the OWASP Top 10, a standard awareness document representing a broad consensus about the most critical security risks to web applications.

Important details

One important detail is that, although all routes are now secure, we are calling the protection twice: One on the middleware.ts and another on the protected route itself. Fortunately, they offer great documentation on avoiding such problems — we simply have to exclude the protected routes of the middleware with the middleware pattern-matching.

import arcjet, { createMiddleware, detectBot } from "@arcjet/next";
export const config = {
  // matcher tells Next.js which routes to run the middleware on.
  // This runs the middleware on all routes except for static assets
  // and now, the api/protected_route path too!
  matcher: ["/((?!_next/static|_next/image|favicon.ico|api/protected_route).*)"],
};
const aj = arcjet({
  key: process.env.ARCJET_KEY!,
  rules: [
    detectBot({
      mode: "LIVE", 
      block: ["AUTOMATED"], 
    }),
  ],
});

export default createMiddleware(aj);

Another really important detail is that, currently, Arcjet’s solution works with the latest Next.js major version — 14.x. Although it’s a really interesting version with a bunch of new features to improve performance and development experience, it’s important to have that in mind. It also needs Typescript to be in the latest major version — 5.x, so, keep that in mind when adding the package!

Conclusion and Personal Thoughts

In conclusion, we've seen how simple it can be to implement robust security measures in our projects, even when we're pressed for time or working solo. By using the power of tools like Arcjet, we can ensure our applications are protected against threats like bots and excessive requests.

Honestly, my experience was really positive. The implementation took just a few minutes and it was easy to see the results since the website UI is well made. The only time I needed to reach out to support was because I didn't have the correct Next.js version — and because of that, the SDK wasn’t working. Since this type of small compatibility issue is common in alpha products, a quick bump made everything work.

Remember, every project, no matter how small or seemingly insignificant, deserves to be secure. So, take this knowledge, apply it to your own projects, and let us know your experiences. If you've used Arcjet or similar tools, we'd love to hear about your experiences in the comments.

5 Reasons Why Your Side Projects Fail to Make Money And How to Avoid Them

Lucas Lima do Nascimento — Wed, 19 Jun 2024 14:10:12 +0000

Introduction

Hello there! If you're like many aspiring entrepreneurs (including me), you've probably had your fair share of bright ideas but struggled to turn them into profitable side projects. You're not alone. Many side projects fail to make money, and understanding why is the first step towards success. So let's dive into the common pitfalls of the solopreneur/indiehacker journey and learn how to avoid them.

Starting this journey, it's important to remember that failure is not the enemy. It is, in fact, a crucial part of the process. Yes, that’s the hard truth: No one ever succeeded by doing something first try.

Embracing failure and learning from it is what helps us avoid making the same mistakes in the future. So buckle up, because we're about to explore the common reasons why side projects fail and how to navigate around them.

Mistake #1 - Not trying it out

This is a tweet from @levelsio, a successful solopreneur, making over $150K/month and it’s a great example to check out. The fear of failure often holds us back from taking that first step. Don't let this fear stop you! It's better to try and fail than to never try at all.

Moreover, keep in mind that not trying at all means you're missing out on valuable experiences and opportunities for growth. Even if your project doesn’t turn out to be profitable, the skills and experience you gain are really the point here. Whether it's enhancing your problem-solving abilities, learning more about a new market, or understanding its dynamics, these skills can be incredibly beneficial in your future projects and interviews.

So, the next time you have an idea for a side project, go for it! Allow your curiosity and passion to drive you, and don't let the fear of failure hold you back. Fail and learn with your mistakes, over and over again — this is the best way to grow as shown by @levelsio.

Mistake #2 - Failed Ideation

You've got this idea. But was it formed through effective brainstorming and problem-solving? One common pitfall in side projects is rushing the ideation process. A thorough brainstorming process is crucial to ensure the viability of your idea.

Try to use your own lenses to filter out ideas that you don’t have that much in common with. The more native the problem is to you, the more obvious and doable the solution seems.

Validate your idea: It's not enough to think it's good. You need to have at least some assurance that there's a market for it. Conduct surveys, ask people you trust, and gather as much initial data as you can.
Make sure your idea solves a problem: A good business idea is one that fills a gap in the market or solves a problem that people are experiencing.
Evaluate your resources: Do you have the skills, time, and money to turn your idea into a business? Be honest with yourself. Always remember that you can do an MVP (minimum viable product), but, if the MVP doesn’t give real value to the users, it won’t suffice.

Want an example? Check this interview with Erlis, creator of amicus.work. It precisely shows how being close to the problem makes the solution intuitive. If you find yourself stuck, you can have a quick read at this other article, or, if you’d prefer a more deep dive Make Book or The Lean Startup are great references too, since they provide valuable insights into avoiding common mistakes during the ideation phase.

Mistake #3 - The infinite build

And there you are: Technology choices flipping through your mind, and you're actually considering learning a whole new programming language just to solve this new problem. Come on, you already read an article on learning! Nothing can stop you!

But, wait! Think about it. Now you have to fight against two problems at the same time:

Learning a new language,
AND CREATING THE SOLUTION TO YOUR PROBLEM.

Turning a fantastic idea into a thriving business is challenging enough already. And you already know that many side projects fail during the building phase, so why do this to yourself?

The secret here? Innovate, but with caution!

Try things that can always speed you up way more than burden you and slow you down. An example? Already know React? Try Wasp , a full-stack framework that takes care of Boilerplate (e.g. Auth) for you and uses AI generation capabilities to help you create products even quicker.

When trying to create and test an idea, we are not looking too much into learning new stuff, rather it is more about creating the idea itself. So when choosing tools, choose ones that are based on technologies you already know and will help you move fast!

By the way: Wasp are the ones making this article possible and, recently, we released Open SaaS — an excellent, 100% free and open-source way to quick-start your new SaaS. Check it out!

⭐️ Create your SaaS with Open SaaS 🙏

Other really common mistake is striving for perfection, which often leads to endless tweaking and delays. Remember, "Done is better than perfect." It's crucial to complete your project and get it out into the world. If your project was seen by no one, it’s just an idea.

Mistake #4 - The never arriving feedback

Delays aren't the only stumbling block in this phase. Sometimes, we're so consumed with creating the perfect product that we forget to validate it with actual users. Regular feedback is crucial - it helps you make necessary changes and ensure your product meets the users' needs.

Without feedback, you’ll never know if you hit the jackpot or if you’re creating a solution for a problem that no one has.

So, how do you make sure you're getting the necessary feedback? Start by testing your product with a small group of users. This could be a group of friends, family, or even a dedicated focus group. Their feedback is valuable in identifying any issues or areas of improvement.

It’s really common that we face the fear of receiving negative feedback too, which often leads to withholding the product from the market until it's 'perfect'. This approach, however, can be harmful. It's vital to ship your product as early as possible, even if it's lacking some of the cool features you're planning to add. Early feedback from users can lead you to add features you hadn't previously thought of but, are the features the actual users want.

Remember, feedback is a gift. It allows you to improve your product and make it something that people not only use but love. So, don’t shy away from it, embrace it!

Mistake #5 - A shy launch

And talking about being shy: So, you've built it, now what? It's time to present it to the world. Yet, remember, timing is everything. If you do a launch that is shy and badly planned, you won’t get the users (neither the revenue) you need.

The first step here is to understand your audience and select the appropriate platform. Reddit is excellent for open-source or projects not primarily driven by profit, while, Dev Hunt, Product Hunt, and Hacker News (YC) are wonderful for a broader spectrum of projects. Choosing the right place to launch can mean the difference between a business and nothingness.

Moreover, creating a strategic launch plan is crucial. It's not enough to just publish your project and hope for the best, although it can happen. You need to plan your launch, considering factors such as the right time to launch, the platform's mannerisms, and adjust your communication to your target audience.

A well-thought-out launch plan will not only help you reach a wider audience but also increase the chances of your project's success. You should use tools like Screen Studio and Canva to help you create beautiful screen recordings and promotional images/banners.

As a bonus, here's an example launch plan to get you started:

Week 1: prepare all promotional materials, like images and videos
Week 2: Launch on Dev Hunt + promote on social media
Week 3: Launch on Product Hunt + Show HN
Week 4 & beyond: Be loud! Continue to promote (without getting banned) on places like Reddit, HN, and other social media platforms.

And hey, you’re on the internet, so, although you might get good feedback, some users will just attack you personally. It's normal, so just ignore the angry people. It’s definitely not a great sensation to have your idea annihilated by some random reddit user, but every now and then you’ll actually get some great insight from an honest user too. It's not easy, but try to recognize which feedback to take seriously, and which to ignore :)

Looking for more?

Interested in more content like this? Follow our blog at Wasp - DEV Community and give us a star on github. This is the easiest way to support us!

⭐️ Star Wasp on GitHub 🙏

Conclusion

In conclusion, transforming a side project into a successful business is a journey filled with challenges and triumphs. Along this journey, each step, be it a hurdle or a victory, is a valuable opportunity to learn and grow.

Each failure is not an end, but a stepping stone towards greater success, serving as a lesson that propels us forward. Every setback is a chance to reassess, refine, and come back stronger. Embrace the iterative nature of this process: continue to refine your ideas, persistently strive for improvement, and most importantly, never stop trying and learning.

📕 Start-ups vs. Big Companies: The Best Takeaways For You To Know 📊

Lucas Lima do Nascimento — Wed, 15 May 2024 12:00:00 +0000

I still remember my first day joining a corporate meeting with hundreds of other employees. After a few months of having some successful freelancing jobs, I finally was able to join a big company and the mixture of anxiety and excitement was real. The challenges were now, different, the stakes were higher, and the environment was overwhelming.

But that’s not the only case I got stressed out from. I also clearly remember a day while working on a small startup when I was presenting to the whole company part of the new front-end architecture we were going to use. We were small enough that every person in the meeting was listening with attention to the words I said.

From being a huge voice in a start-up to becoming a small part of a larger pack in a corporation, every experience has its own set of learnings.

Of course, that’s not always the case. Out there, we all know that unprepared companies exist and that’s why this article was created. Here, we will explore some of the key learnings and takeaways I got while working on both, start-ups and big companies, so you can learn it agnostically from the company you currently work at and even decide your next career steps on your own, to see which of them is more your fit.

Processes and Culture

Let’s start with the processes since they are the first very obvious difference. While working on a start-up most of the processes are still being implemented and a huge part of your work can actually involve trying and experimenting with different processes for those tasks.

Culture can also be in the creation phase, so, the shared values that define a company and its people, or the 'way things are done around here.' can change a lot and rapidly!

Of course, this makes the experience way more chaotic but also more flexible. It’s not uncommon to juggle multiple roles and responsibilities, which can be a great opportunity to learn and grow in different aspects, for example, creating new good cultural patterns.

On the other hand, in a more corporate environment, processes are more structured and defined, which can provide stability and clear expectations, but come on the downside of bureaucracy, taking a long time to actually move through multiple pipelines and funnels.

The key takeaway here is balance. Scarcity in processes makes the whole ecosystem chaotic, which is uncomfortable, but too much process and you will not get anything done. Balancing the weights on the absence and the overflow will create a better environment for everyone.

Agility and Adaptability

Working in a startup often involves wearing multiple hats and adapting to changes on the fly. In a fast-paced startup environment, agility and adaptability are key. You have to be ready to pivot, which can make you grow a lot in terms of not getting too attached to your ideas. You also have to be ready to adjust your strategies and embrace new technologies and methodologies if they seem fit.

This can be a thrilling experience that fosters creativity and innovation but also can lead in the long term to a dispersed and stressful environment (where all aspects of your company are on different technologies, and making all that chaos work is HARD).

In contrast, big companies have the luxury of time and resources, allowing for more thorough planning and execution. Also, big companies tend to rely on things they already trust and generally are not too open to new things.

While this is less exciting than the dynamic startup environment, it offers a different type of learning experience. Here, you can deepen your understanding of strategic planning, project management, and other aspects of business operations.

The key takeaway here is learning to be agile, versatile, and adaptable when it’s needed. If you don’t want to take my word for it, I recommend reading this article about boring technology. It’s amazingly insightful and a great read!

OH! And before I forget, this article is only possible because of Wasp, and they’re building a full-stack React + NodeJS framework that’s really cool and it would mean a lot if you could help us by starring our repo on GitHub.

By doing that, you're helping us continue to make web dev faster and easier, and bring content like this to you every week! 🚀

⭐️ Give us a star on GitHub 🙏

Networking Opportunities

Another major difference between startups and big companies is the networking opportunities they provide. Big corporations often have a wide network of employees, clients, vendors, and partners. Working in such an environment can open up numerous opportunities for networking and building valuable professional relationships. These connections can be incredibly beneficial for your career growth.

On the other hand, startups, due to their smaller size, offer more intimate networking opportunities. You'll likely work closely with every member of your team, giving you the chance to form stronger relationships and learn directly from your colleagues and superiors.

The key takeaway here is to embrace every connection and try to create a great working environment everywhere you go. This will allow you to sustain rough periods more easily and you’ll certainly grow some friendships for all your life 😃

Impact

Now, let’s talk about impact. On larger companies, your codebase is probably accessed by thousands (more probably millions) of people. This means that making a small change can alter the way a lot of people perceive the application and it’s enormously satisfying to see your work being utilized by so many. Unfortunately, the first time you have to deploy a small code change for a code base accessed by millions of users is ABSOLUTELY nerve-wracking — although necessary for increasing your experience and resilience.

On start-ups, you’re probably looking at a codebase accessed by hundreds (with faith thousands). This means, that your work will be seen by fewer people, but, since you can create a lot more, you are probably going to create much more than just a small change. Pages, user journeys, and everything can be at your range alone or with your team. It doesn’t come without a drawback though. Since processes are more scarce, rollbacking and reverting changes can sometimes be a hard (or even worse, undocumented) process.

The key takeaway here is the importance of understanding your role and the value you bring in different environments. Whether you are in a startup where your work directly drives the company's success, or in a larger corporation where your actions contribute to a broader goal, your work matters and you should feel proud of it.

Just to give an example, I’m really proud of making a simple product filter on a huge e-commerce website (that they use until today) and I’m also really proud of implementing/participating actively in the implementation of at least 2/3 of every component of a new design system brought up by the designers of the start-up I used to work with. Good work doesn't invalidate others.

Conclusion

If this journey through the realms of startups and corporations has left you inspired, why not lend your support to Wasp? We're crafting tools and content to empower developers like you, whether you're coding solo or conquering corporate challenges.

If you want to see more content like this, you can help us out really easily by giving us a star on GitHub!

⭐️ Star Wasp on GitHub 🙏

Start-ups and big corporations both offer valuable experiences. In a start-up, you get to do different tasks, try out new things, and directly affect the company's future. It's a hands-on learning experience.

In a big corporation, you have access to many resources and a structured environment. You can work with a team of diverse experts, which helps you learn and grow. The established processes, stability, and predictability can help improve your skills and shape your career.

But, it's not about choosing one over the other. It's about learning to do well in both environments. Take the best parts from both and use them wherever you are. Be agile, adaptable, and open to new experiences. Both experiences are important for your career.

In conclusion, every environment has its own unique set of challenges and opportunities. Embrace the differences, learn from the experiences, and leverage them to your advantage. After all, it's these diverse experiences that help you grow both personally and professionally. So, whether you're in a start-up or a big corporation, always remember - your work matters and it contributes to the bigger picture.

What are your thoughts on this comparison between startups and big corporations? We'd love to hear your experiences and takeaways. Please share your thoughts in the comments below!