DEV Community: Maria Baptista

Why Salesforce? Where Technology Meets Business

Maria Baptista — Sun, 30 Aug 2026 19:29:04 +0000

As a software developer, I have always been interested in the point where technology stops being just code and starts solving a business problem.

That is one of the reasons Salesforce interests me now.

Salesforce is not simply a CRM platform. It is an ecosystem where customer data, business processes, automation, applications, analytics and increasingly artificial intelligence can come together.

For someone with a technical background and experience across development, automation, customer interaction, sales and digital processes, that combination is particularly interesting.

Understanding Salesforce as a CRM

At its core, Salesforce helps organizations manage relationships and interactions with their customers.

But the platform becomes much more interesting when we look at how its different building blocks work together.

Some of the fundamental concepts include:

Accounts
Contacts
Leads
Opportunities
Cases

These objects represent different parts of a company's relationship with customers and prospects.

For example, a Lead can represent a potential customer.

An Account can represent a company or organization.

A Contact represents a person associated with an account.

An Opportunity represents a potential business opportunity.

And a Case can represent a customer service issue that needs to be managed.

Understanding these relationships is important because CRM is ultimately about understanding the customer journey and the processes surrounding it.

Sales Cloud

Sales Cloud focuses on supporting sales processes.

The concepts of Leads and Opportunities are particularly important here.

A company might start with a potential lead, qualify that lead, and eventually manage a business opportunity through different stages of the sales process.

Technology can then help make this process more organized, measurable and automated.

This connects closely with my own experience.

I have worked with lead generation, digital marketing, WhatsApp communication and the handoff of potential customers to business teams.

That experience made me interested in the technological side of the same process.

Instead of simply generating and forwarding leads, CRM platforms can provide a structured environment for managing the entire relationship.

Service Cloud

Sales is only one part of the customer relationship.

After a customer becomes a customer, support and service become equally important.

This is where Service Cloud becomes relevant.

Cases can be used to organize customer issues, requests and support processes.

My experience at CLYRA included two months working directly with customer support, helping users with questions and problems related to the platform.

That experience gave me a practical understanding of something important in CRM:

Customer experience does not end when the sale happens.

Automation with Salesforce Flows

One of the concepts that I understand just living as a Developer is automation through Salesforce Flow.

A business process often contains repetitive steps.

Instead of requiring a person to manually perform every action (~~_Imagine running a huge company and having to type in data for millions of people~~... nowadays, it makes no sense)_, so, a flow can automate parts of the process based on defined conditions and events.

This immediately connects with my previous experience using n8n.

Although the technologies and platforms are different, the underlying idea is familiar:

«Understand the process → identify repetitive actions → define conditions → automate the workflow → validate the result.»

This is one of the reasons I believe my existing automation experience can provide a strong foundation for learning Salesforce.

Configuration vs Development

Another distinction that interests me is the relationship between configuration and development.

A Salesforce solution does not necessarily require custom code for every requirement.

Sometimes the platform's existing capabilities and configuration options are enough.

Other situations may require custom development.

Understanding when to configure and when to develop is therefore not only a technical question.

It is a solution-design question.

The goal should not be to write more code.

The goal should be to build the most appropriate solution for the customer's requirements.

Lightning and the Salesforce Platform

The Salesforce Platform provides an environment for building and extending business applications.

Lightning provides the modern experience through which users interact with Salesforce and its applications.

For someone coming from web development, concepts such as components, interfaces, data, workflows and application logic provide interesting connections with technologies I have already worked with.

My background in JavaScript, React, Node.js, APIs and UI/UX gives me a foundation for understanding these concepts while learning the Salesforce-specific ecosystem.

Apex — Conceptually

Apex is Salesforce's programming language for developing custom logic on the platform.

I am approaching Apex from the perspective of understanding where custom programming fits into the Salesforce ecosystem.

Coming from JavaScript and Node.js, I already have experience with programming logic, APIs, backend development and application architecture.

The syntax and platform-specific concepts are different, but the underlying software engineering principles remain relevant:

Clear logic
Maintainability
Separation of responsibilities
Error handling
Testing
Understanding requirements

The goal is not simply to learn another syntax.

It is to understand how development works within the Salesforce platform.

Dashboards and Business Visibility

Data becomes much more useful when it helps people make decisions.

Salesforce dashboards and reports can transform CRM data into information that business teams can actually use.

For example, an organization might want to understand:

How many leads are being generated?
How many opportunities are active?
Which opportunities are progressing?
How quickly are customer cases being resolved?
Where are potential bottlenecks in the sales process?

This is where CRM moves beyond data storage.

It becomes a decision-support system.

Permissions and Trust

A CRM contains sensitive business and customer information.

That makes permissions and access control an important part of Salesforce.

Different users may need different levels of access depending on their responsibilities.

Understanding who can see, modify or manage information is therefore part of designing a responsible business solution.

This is another reminder that enterprise software is not only about functionality.

It is also about governance, security and trust.

Salesforce and Artificial Intelligence

The evolution of Salesforce towards AI is another reason I find the ecosystem good to explore.

AI can potentially help organizations work with their customer data more intelligently, assist users and automate parts of business processes.

But I believe the same principle applies here as in software development:

AI should amplify human judgment, not replace it.

Good AI implementation starts with understanding the business problem.

Without that understanding, adding AI simply because it is available does not necessarily create value.

Why Salesforce?

So, why Salesforce?

Personal goals...
Because it sits exactly at an intersection that interests me:

Technology + Business + Customers + Automation + AI.

My experience is not limited to software development.

I have worked with:

Web development
APIs
Automation
UI/UX
Artificial Intelligence tools
Customer support
Lead generation
Digital marketing
Business processes

Salesforce gives me an opportunity to bring these experiences together while developing deeper expertise in CRM and enterprise technology.

I am particularly interested in learning the platform in a real consulting environment, understanding customer requirements, contributing to implementations and continuously developing my technical and business skills.

I don't see Salesforce as simply another technology to add to my CV.

I see it as an opportunity to become better at something I find increasingly important in technology:

building solutions that make sense not only technically, but also for the people and businesses using them.

Learning by doing! Dev.to friend's! Even though I'm already familiar with the concepts, I'm taking a 52-hour course to sharpen my skills. I've just hit the 10% mark, and my goal is to finish it in 5 days, posting every new progress right here in the comments! Stay tuned and share with me. 🐞

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