DEV Community: MARIA BAPTISTA

Salesforce? What We Should Know

MARIA BAPTISTA — Sun, 30 Aug 2026 19:29:04 +0000

Honestly, I have always preferred traditional programming, but I recently started learning about Salesforce, although it was not for the best reasons... What brought you to it?

I started taking a course after becoming interested in a job opportunity and, well, I am enjoying it.

Building an application is one thing. As developers, we understand why a company needs a particular solution, but we may not be sure how people will use it. That is why it is important to constantly think about how technology can improve an existing process.

Salesforce is exactly that.

As I explore the platform, I see connections with things I have worked with before: web development, APIs, automation, customer support, lead generation, and AI-assisted workflows.

Is Salesforce Just a CRM?

When I started researching Salesforce, I mainly saw it as a CRM.

Of course, CRM is an important part of it. But there is much more than that.

Customer data, sales processes, support, automation, permissions, analytics, and applications, all within the same ecosystem.

Leads, Accounts, Contacts, Opportunities, and Cases were some of the first concepts I explored. Of course, you have to start with the basics.

What I find interesting is not just knowing what each object means. It is understanding how they represent a real business process.

If you are new to this, just like me, then let’s dive into the explanations:

A Lead can become an Opportunity. A customer may need support. Different people within a company may need different levels of access to the same information.

When we start seeing things this way, Salesforce stops being just about memorizing platform terminology and becomes a way to understand how a business works.

Sales Cloud and My Previous Experience

I will talk a little about my previous experience with lead generation and digital processes.

I have worked with lead generation, digital marketing, and communication through WhatsApp, including processes in which potential customers had to be routed to sales teams.

That made me think about what happens after a lead is generated.

Which steps can be automated?

Before, I mainly analyzed these questions from a digital and operational perspective. Salesforce gives me the opportunity to understand the same processes from a CRM and technology perspective.

Service Cloud

Another connection comes from customer support.

During my time at CLYRA, I also worked directly with customer support, helping users with questions and issues related to the platform.

That experience taught me something simple but important:

The customer experience does not end when a sale is completed. It is not just about paying and walking away.

There are questions, problems, requests, and follow-ups that need to be handled properly.

That is why the idea behind Service Cloud makes sense to me. A support request should not become just another message lost in a conversation. It can be part of a structured process that can be tracked, prioritized, and improved.

Learning Automation with Salesforce Flow

Automation is probably one of the areas where I said I would shine.

I have worked with n8n, so the idea of analyzing a process and asking, “What can be automated?” is exactly what I mentioned earlier. I love automating processes. Why not make things simpler? Of course, always with human oversight.

Salesforce Flow is a different technology, but at its core, the logic is the same. It is simply a matter of understanding the basics:

Understand the process → find repetitive steps → define conditions → automate → test the result.

For example, instead of asking someone to manually perform the same action whenever a certain condition is met, a flow can handle that process automatically. Simple.

Configuration or Development?

Coming from a software development background, it is easy to think that every problem requires code.

Sometimes, the platform already provides the functionality needed to solve a requirement. In other situations, custom development makes more sense.

For me, learning Salesforce also means learning how to make that distinction.

The goal is not to write as much code as possible.

It is to understand the requirement and choose an appropriate solution.

Where My Development Experience Fits In

My experience is in software development, digital marketing, and sales, so I naturally started looking for connections between Salesforce and the technologies and processes I already know.

I have worked with JavaScript, React.js, Node.js, APIs, and UI/UX, as well as automation and AI tools.

Lightning, components, data models, APIs, and business logic are not completely unfamiliar concepts to me.

There is still a lot to learn and explore. And I love that.

Apex

You need to have a developer mindset.

Apex is not simply “JavaScript with a different syntax.”

Salesforce has its own architecture, limits, and way of working, so learning Apex also means understanding how development fits into the platform itself.

Data, Dashboards, and Permissions

Well...

Data needs to be useful.

A company may want to know how many leads are being generated, how opportunities are progressing, how quickly customer Cases are being resolved, and where a process is getting stuck. I know this because I have worked with this kind of information before.

Reports and dashboards transform this data into something people can actually use for decision-making, in a more organized way.

And then we have security.

A CRM can contain a great deal of sensitive business and customer information, so deciding who can access, modify, or manage certain information is an important part of building a responsible solution. Trust me.

Salesforce and AI

AI...

I have been using AI tools in my development workflow, and I am particularly interested because AI is becoming increasingly autonomous instead of being treated as a separate feature.

“Is there a real problem that AI can help solve?”

Whether it is helping users work with information, assisting with repetitive tasks, or making customer data more useful, the business problem should come first.

Technology comes afterward.

So, Why Salesforce?

I think we already know.

Salesforce brings together several areas I have already had contact with:

Software development
APIs
Automation
Customer support
Lead generation
Digital processes
Business requirements
AI

And you may find these connections too.

What I am looking for now is the opportunity to connect these experiences and develop deeper expertise in CRM and enterprise technology.

I am particularly interested in the consulting side because it requires more than technical knowledge.

You need to understand what the client really needs, turn that into a solution, communicate the reasoning behind it, and continue learning along the way.

I do not want Salesforce to be just another technology listed on my résumé.

I want to understand how to use it correctly. And use it masterfully.

Learning Through Practice

I am currently taking a 52-hour Salesforce course to strengthen my foundations.

I have just reached the 10% mark, and I am setting myself a small challenge: finish the course in five days.

I will share my progress here as I move forward, if you comment and share your thoughts with me.

Let’s see how far I can get. 🐞

AI-Assisted Development Without Losing Engineering Judgment

MARIA BAPTISTA — Sat, 29 Aug 2026 12:49:32 +0000

Modern software development gives us access to increasingly powerful AI tools. But using AI effectively is not the same as letting ~~AI make every technical decision.~~

For me, AI is most valuable when it accelerates the development process while the developer remains responsible for architecture, requirements, user experience, integrations and the final result.

This approach became particularly relevant in my work at CLYRA, where I worked across frontend development, backend development, UI/UX, automation and external integrations.

AI as Part of the Development Workflow

At CLYRA, Lovable was an important part of my development workflow.

Rather than treating it as a replacement for development, I used AI-assisted tooling to accelerate activities such as prototyping, exploring interfaces and moving ideas towards implementation.

The important part was not simply generating code.

The important part was deciding:

What should be built?
What should the user experience look like?
How should different services communicate?
What belongs in the frontend?
What belongs in the backend?
How should an external API be integrated?
How should the resulting functionality behave in a real product?

AI could accelerate the path from an idea to an implementation, but engineering judgment remained essential.

React, Node.js and Tailwind CSS

My work also involved technologies that sit at the core of modern web development.

I worked with:

React.js
Node.js
Tailwind CSS
JavaScript
REST APIs
UI/UX
n8n
External service integrations

This allowed me to work across different parts of a product rather than focusing exclusively on one layer.

On the frontend, React and Tailwind CSS supported the development of modern interfaces.

On the backend, Node.js enabled application logic and integrations.

And between systems, APIs connected the different services required by the product.

Automation with n8n

Another important part of the workflow was automation.

I worked with n8n to create and manage workflows, connecting different services and reducing repetitive manual processes.

This is one of the areas where I find the combination of AI and automation particularly interesting.

AI can help accelerate the creation and exploration of solutions.

Automation can make those solutions repeatable.

But someone still needs to understand the business process being automated.

That distinction matters.

A technically impressive automation that solves the wrong problem is still the wrong solution.

Integrating Real-World Services

The work at CLYRA also involved integrations with external services, including:

WhatsApp API

Used as part of communication and platform workflows.

QR Codes

Used as part of the product's digital interaction flows.

Stripe

Used for payment functionality and plan management.

These integrations reinforced something that is easy to overlook when learning software development:

«A product is rarely just the interface.»

A real application needs its frontend, backend, APIs, authentication, automation, payments and user experience to work together.

Customer Support Changed How I Think About Software

For two months at CLYRA, I also worked in customer support.

(I am highlighting my corporate experience at Clyra because my prior experience involved more autonomous roles with fewer administrative constraints)

Customers contacted the team with questions and problems related to the platform, and we helped them understand and resolve those issues.

That experience was valuable because it put me on the other side of the product.

A feature can work technically and still be confusing to the person using it.

A workflow can be logically correct and still fail to solve the customer's actual problem.

This is one reason I consider customer understanding an important part of software development.

Building Without AI

AI-assisted development is powerful, but I don't consider it a requirement for building software.

I am also _comfortable developing projects _using conventional engineering practices and technologies without relying on AI to generate the solution.

One example is Kwendi, a project focused on technology, education and the learning of Umbundu.

The project involves product thinking, application architecture, UI/UX and the design of a learning experience.

The important lesson for me is simple:

AI is a tool. It is not the developer.

A strong developer should be able to work with AI when it creates value, but should also be able to reason about a problem, design a solution and build software independently.

What I Take From This

My approach to modern software development can be summarized in four ideas:

Understand the problem → Design the solution → Use the right tools → Validate the result.

Sometimes the right tool is AI.

Sometimes it is automation.

Sometimes it is simply writing the code yourself.

The technology should serve the problem — not the other way around.

And that is where I believe AI-assisted development becomes genuinely powerful: when it increases the developer's ability to experiment, learn and deliver without removing responsibility for the final solution.

Building a Full Stack App with .NET and Angular the TDD Way

MARIA BAPTISTA — Fri, 19 Sep 2025 16:19:19 +0000

In this hands-on guide, we'll build a full-stack application from scratch using .NET for the backend and Angular for the frontend, but with one golden rule: no production code is written unless a test fails first. Welcome to the world of TDD!

The Challenge: Confidence in Your Code

How many times have you fixed a bug, only to accidentally break another part of the system? Or implemented a new feature, fearing that something might go wrong in production? A lack of confidence in our own code is one of the biggest enemies of a developer's productivity and peace of mind.

The solution? A safety net. A suite of automated tests that ensures your application behaves exactly as expected. And the best way to build this net is to weave it as you build the application itself.

In this article, we'll build a simple to-do list application using a modern stack:

Backend: .NET 7 Web API
Frontend: Angular 14+
Methodology: Test-Driven Development (TDD) from end to end.

Our golden rule will be the classic TDD cycle:

Red -> Green -> Refactor.

Red: Write a test that fails because the feature doesn't exist yet.
Green: Write the simplest possible code to make the test pass.
Refactor: Improve the code without changing its behavior (and without breaking the test).

Let's start with the backend.

Part 1: The Test-Driven .NET Backend

Our goal is to create a GET /api/tasks endpoint that returns a list of tasks.

Step 1: Red - Writing the First Test

First, we create a test project (using xUnit, NUnit, etc.) and write a test for our future TasksController.

// In the Test project (e.g., Tasks.API.Tests/TasksControllerTests.cs)

public class TasksControllerTests
{
    [Fact]
    public async Task GetTasks_WhenCalled_ShouldReturnOkWithListOfTasks()
    {
        // Arrange
        // The controller doesn't even exist yet, but we're already defining how it should behave.
        var controller = new TasksController(); // <-- This will cause a compile error!

        // Act
        var result = await controller.GetTasks();

        // Assert
        var okResult = Assert.IsType<OkObjectResult>(result);
        var tasks = Assert.IsAssignableFrom<IEnumerable<TaskItem>>(okResult.Value);
        Assert.NotEmpty(tasks);
    }
}

At this point, the code doesn't compile. TasksController doesn't exist, the GetTasks method doesn't exist. Perfect. We are in the Red phase.

Step 2: Green - Making the Test Pass

Now, let's go to our API project and write the simplest possible code to make the test compile and pass.

First, the TaskItem model:

// In the API project (e.g., Tasks.API/Models/TaskItem.cs)
public class TaskItem
{
    public int Id { get; set; }
    public string Title { get; set; }
    public bool IsCompleted { get; set; }
}

Now, the TasksController:

// In the API project (e.g., Tasks.API/Controllers/TasksController.cs)
using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/[controller]")]
public class TasksController : ControllerBase
{
    [HttpGet]
    public async Task<IActionResult> GetTasks()
    {
        // Warning: We are hardcoding the data.
        // This is the shortest path to "Green". Refactoring comes later.
        var tasks = new List<TaskItem>
        {
            new TaskItem { Id = 1, Title = "Learn TDD", IsCompleted = true }
        };

        // We use Task.FromResult to simulate an async operation
        return await Task.FromResult(Ok(tasks));
    }
}

If we run our test now, it should pass. We are in the Green phase.

Step 3: Refactor - Improving the Code

The code works, but it's using a hardcoded list. Let's refactor it to use a service, preparing for a future database connection, without breaking our test.

First, the service interface:

public interface ITaskService
{
    Task<IEnumerable<TaskItem>> GetAllAsync();
}

Now, the refactored TasksController using dependency injection:

public class TasksController : ControllerBase
{
    private readonly ITaskService _taskService;

    public TasksController(ITaskService taskService) // Dependency Injection
    {
        _taskService = taskService;
    }

    [HttpGet]
    public async Task<IActionResult> GetTasks()
    {
        var tasks = await _taskService.GetAllAsync();
        return Ok(tasks);
    }
}

Of course, our test now breaks because the TasksController constructor has changed. This is good! The test is protecting our architecture. Let's adjust it using a mock (with libraries like Moq or NSubstitute).

// Adjusted Test
[Fact]
public async Task GetTasks_WhenCalled_ShouldReturnOkWithListOfTasks()
{
    // Arrange
    var mockService = new Mock<ITaskService>();
    mockService.Setup(service => service.GetAllAsync())
        .ReturnsAsync(new List<TaskItem> { new TaskItem { Id = 1, Title = "Test" } });

    var controller = new TasksController(mockService.Object);

    // Act
    var result = await controller.GetTasks();

    // Assert
    // ... same assertions as before
}

We run the tests again. Everything is Green. We now have cleaner, decoupled, and equally functional code.

Part 2: The Test-Driven Angular Frontend

Let's apply the same logic in Angular to create a component that displays the tasks.

Step 1: Red - Testing the Component

The Angular CLI already creates a test file (.spec.ts) for us. Let's modify it to test if our TaskListComponent calls the service and renders the data.

// task-list.component.spec.ts

describe('TaskListComponent', () => {
  let component: TaskListComponent;
  let fixture: ComponentFixture<TaskListComponent>;
  let mockTaskService: jasmine.SpyObj<TaskService>;

  beforeEach(async () => {
    // We create a spy for our service
    mockTaskService = jasmine.createSpyObj('TaskService', ['getTasks']);

    await TestBed.configureTestingModule({
      declarations: [TaskListComponent],
      providers: [{ provide: TaskService, useValue: mockTaskService }]
    }).compileComponents();

    fixture = TestBed.createComponent(TaskListComponent);
    component = fixture.componentInstance;
  });

  it('should call getTasks on init and render the tasks', () => {
    // Arrange
    const tasks: TaskItem[] = [{ id: 1, title: 'Test the component', isCompleted: false }];
    mockTaskService.getTasks.and.returnValue(of(tasks)); // Simulate the Observable's return

    // Act
    fixture.detectChanges(); // Triggers ngOnInit and the component's lifecycle

    // Assert
    expect(mockTaskService.getTasks).toHaveBeenCalled(); // Was the service called?

    const element: HTMLElement = fixture.nativeElement;
    const taskTitle = element.querySelector('li');
    expect(taskTitle?.textContent).toContain('Test the component'); // Was the title rendered?
  });
});

This test will fail. Our component is empty. We are in the Red.

Step 2: Green - Implementing the Component

Now, let's write the minimal code in the component and template to make the test pass.

// task-list.component.ts
@Component({
  selector: 'app-task-list',
  templateUrl: './task-list.component.html',
})
export class TaskListComponent implements OnInit {
  tasks$: Observable<TaskItem[]>;

  constructor(private taskService: TaskService) {}

  ngOnInit(): void {
    this.tasks$ = this.taskService.getTasks();
  }
}

<!-- task-list.component.html -->
<ul>
  <li *ngFor="let task of tasks$ | async">
    {{ task.title }}
  </li>
</ul>

And the TaskService will make the HTTP call to our .NET API.

If we run the test now, it will pass. Green.

Step 3: Refactor

Our code is already quite clean thanks to the use of the async pipe and Observables. A possible refactoring would be to add error handling (and a test for it!), such as displaying a friendly message if the API fails. But for now, our cycle is complete.

Conclusion: More Than Just Tests

As we've seen, TDD isn't just about writing tests. It's a software design methodology. It forces us to think about the interface and behavior of our components and services before we implement them.

The result is code that is:

More Reliable: The test suite is your safety net.
More Decoupled: The need to mock dependencies encourages dependency injection and a cleaner design.
Better Documented: The tests themselves serve as living documentation of how the system should behave.

Starting with TDD might feel slower at first, but the speed and confidence you gain in the long run are immeasurable. The next time you start a project, try writing a failing test first. It might just be the beginning of a new way of coding.

🚫 No Internet, No Cloud, No Problem: Building Monitoring Systems That Survive Offline

MARIA BAPTISTA — Sat, 12 Jul 2025 05:51:19 +0000

When you think about monitoring infrastructure, what comes to mind?

Maybe dashboards in Grafana, real-time alerts from Prometheus, centralized logs, and seamless cloud connectivity across AWS or GCP...

Well, none of that works here.

🌍 Where I Come From

I’m Maria, a self-taught engineer who has already had many problems of unstable infrastructure.

Somewhere, it’s normal to:

Lose internet multiple times a day
Have speeds under 1 Mbps
See power cuts without warning
Rely on SMS instead of Slack

But guess what? We still have systems to monitor. Critical alerts still matter. And that’s exactly why I started building my own solution.

⚡ The Problem

Traditional observability tools are powerful — but they assume:

High uptime
Fast internet
Access to the cloud

None of those assumptions hold true in large parts of Africa, South America, and Asia. And most engineers in Silicon Valley don’t even realize it.

I needed something different. Something local-first, resilient, and cloud-optional.

🔧 Meet Kuze Alert Monitoring for the Real World

Kuze Alert is my open-source project designed to monitor systems in the harshest, most unreliable environments.

It’s not just another tool. It’s a survival kit for devs like me who work under conditions where “just push to the cloud” doesn’t work.

🧠 Key Features:

✅ Offline-first alert generation
✅ Works on cheap hardware
✅ Sends alerts via SMS or local radio
✅ Compresses and syncs data when internet returns
✅ Integrates with Prometheus locally

I’m currently building it in Go, using Prometheus and edge storage (SQLite/in-memory).

Soon, it will support push/pull sync and even visual dashboards — without internet.

📡 Real-World Scenario

Imagine a small ISP in Luanda that monitors routers in 3 provinces. The internet drops at night — every night.

With Kuze Alert:

Metrics are collected locally
Alerts are fired even offline
Critical events are cached and sent when possible

That’s observability that respects your reality.

💡 Why This Matters (and Not Just to Me)

Over 3.5 billion people live with unstable internet
Cloud-first tools leave these people behind
Most “global” tools break outside high-income regions

I’m building something different. Something grounded. Something I wish someone had built for me.

👩🏽‍💻 Who I Am (and Why I’m Writing This)

I’m young. Woman. I’m self-taught. I’ve been building little systems since I was more younger.

I created this article because I recently discovered the Dev.to community — and I’m absolutely LOVING the energy here.

The people, the projects, the passion — it’s inspiring.

I’m learning more every day, and I finally feel like I’ve found my tech family.

🔗 Follow My Journey

I'm sharing everything I learn while building Kuze Alert, contributing to open source, and growing from Angola to the world.

🌐 GitHub: github.com/mariajtik
💼 LinkedIn: linkedin.com/in/maria-baptista-95b582280

If you’re working with observability, edge computing, or cloud-native systems, let’s connect (some other IT area, would be a pleasure too).

If you’ve ever built tech in low-resource environments, I want to hear your story.

And if this article resonated with you — react, share, or comment.

It helps me grow, and helps this message reach the people who need it most.

✊🏽 Let’s Build a Truly Global Stack

One that works offline.
One that’s resilient.
One that doesn’t leave half the world behind.

Join me. ⭐ Star my GitHub. 💬 Leave your thoughts. 📣 Share this post.

Observability #Monitoring #AfricaTech #OpenSource #DevOps #Prometheus #Grafana #KuzeAlert #EdgeComputing #SelfTaught