Transformative knowledge and technology

We are one of the largest software development companies in Brazil and we serve several segments of high impact to society, offering solutions that are a benchmark for digital transformation in the public and private sectors.

Learn more about Softplan
+ 0 years
years in the market
+ 0
specialized employees
+ 0 awards
national and international awards
+ 0
customers from different segments

Solutions solutions for each sector

Image Digital Transformation Solutions

Digital Transformation Solutions:

We offer digital transformation solutions for several Public Sector institutions.

Imagem MultiSaaS Solutions

MultiSaaS Solutions:

We offer an ecosystem of solutions that meet the recurring business management demands of various segments.

See who has innovated with our software

BTG Actual
City Hall Ribeirão Preto
Barueri City Hall
Cury Builder
Lumis Construction
Unimed Grande Florianópolis
City Hall of Juiz de Fora
Municipality of Balneario Camboriu

What our customers have to say

" goes far beyond simply releasing information in the digital system (...) It encompasses the process from start to end,up to the termination of a contract. Everything is entered into the system. When the contract management operation becomes more than just scanning and uploading documents, but actually processing information."

Humberto Schmidt

Coordinator Project Avança Saúde São Paulo | Municipal Secretary of Health of São Paulo 

"We believe that in the medium term Barueri will be effectively paper free, in particular, starting with the Administration Secretariat. I am very pleased with softplan, which based on what I saw is a very reputable andtransparent company that works with top public bodies, such as our Court of Justice of the State of São Paulo. It is already a very reliable point and, with the competence of the CIT, we will quickly reach success in Barueri and we will be even prouder of our city."

Cilene Rodrigues Bittencourt

Administration Secretary of the Municipality of Barueri

"Sienge is the backbone, the main system. Any other tool that needs to be used by any of the company’s areas has to start from what we have in Sienge."

Sabrina Ribeiro

COO at Cury Construtora

"Assaí strongly values the health of our customers and employees. Easy Checklist allows us to manage all the stores simultaneously, understand improvements and address non-conformities.If it were all on paper, it would be quite complicated."

Natalia Figueiredo

Coordinator of Technical Training in Food Safety at Assaí Atacadista


latest blog posts

See all
Angular: Why you should consider this front-end framework for your company


Angular: Why you should consider this front-end framework for your company

A fear for every team is choosing a tool that will quickly become obsolete. If you've been developing applications for a few years, you've probably already experienced this. Therefore, choosing good tools is a task that involves responsibility, as it can guide the project (and the company) to success or to a sea of ​​problems and expenses. In this article, we will understand the uses and benefits of the Angular framework. Choosing a front-end framework is no different and also involves research and studies. Choosing a “stack”, as we call it in this world, is trivial both for the present and for the future. However, some questions will arise in the midst of this choice: Will we find qualified professionals to deal with this framework? Will we be able to maintain a pace of updates? Is there a well-defined plan for the direction the framework is going? Is there a community (we also mean large companies supporting it here) engaged? All of these questions must be answered before starting any project, as neglecting a screen can lead to devastating scenarios for the product, and consequently for the company and its profits. Motivations for using a framework Perhaps the most direct answer is that sometimes it's good not to keep reinventing the wheel. Routine problems such as dealing with routes for a web application, or even controlling dependencies, generating bundles optimized for publication in production, all of these tasks already have good solutions developed, and, therefore, choosing a framework that gives you this set of tools is perfect for gaining productivity, solidity in the development of an application and also keeping it always updated following best practices. As well as the direct motivations, I can also mention: The ease of finding tools that integrate with the framework The search for quality software, integrated with tests and other tools that will make the development process mature Many situations and problems have already been resolved ( because there are a lot of people working with the technology) Motivations for using the Angular framework: Built using Typescript, one of the most popular languages ​​at the moment MVC Architecture Control and Dependency Injection Modularization (with lazy load option) Good libraries for integration Community large and engaged 1835 contributors in the official repository Officially supported and maintained by the Google team The solidity of Angular Currently, we can clearly state that the framework is stable, receiving frequent updates due to its open-source nature. This is because it is maintained by the Google team, which always seeks to make the roadmap of what is to come as clear as possible, which is very good. Furthermore, the Angular community is very active and engaged. It's difficult to have a problem that hasn't already been resolved. One of the concerns of every developer is regarding drastic changes to a tool. Anyone who lived through the change from V1 to V2 of Angular knows this pain, the change was practically total. However, the framework was correctly based on Typescript, which brought robustness and another reason for its adoption: with Typescript, we have possibilities that Javascript alone cannot solve: strong typing, integration with the IDE, making life easier for developers , error recognition at development time, and much more. Currently, the framework is in version 17 and has been gaining more and more maturity and solidity, with the increase in innovative features such as the recently launched defer. Easy upgrade The framework provides a guideline for every upgrade through the website, this resource helps a lot to guide the update of your project. Complete CLI Angular is a framework. Therefore, when installing your package we will have the CLI ready to launch new projects, generate components, run tests, generate the final package and maintain updates for your application: To create your first project, simply open your terminal and run the command a follow: Solid interface designs If you need a design for your application that provides ready-to-use components such as alerts, modal windows, snackbar notices, tables, cards, one of the most popular possibilities is choosing Angular Material, a good The point to follow your software with it is because it is maintained by Google, so whenever the framework advances in version, Material usually follows this update. In addition to Material, there are other options in the community, such as PrimeNG, which brings a very interesting (and large) set of components. Nx library support Angular has full support for the Nx project, which makes it possible to scale your project in a very consistent way, mainly guaranteeing caching and advanced possibilities for you to maintain and scale your local application or in your CI environment. Here are some specific examples of how Nx can be used to improve an Angular project: You can create an Angular library that can be reused across multiple projects. You can create a monorepo that contains all your Angular projects, which makes cross-team collaboration easier. You can automate common development tasks like running tests and deploying your projects. Tests (unit and E2E) In addition to Karma and Protactor that were born with the framework, you are now free to use popular projects like Jest, Vitest and Cypress. State with Redux One of the most used libraries by the community is the NgRx Store, which provides reactive state management for Redux-inspired Angular applications. Brazilian GDEs In Brazil we currently have two Angular GDEs, which is important for our country and also for generating Angular content in Portuguese, bringing always updated news and insights to our community straight from the Google team. Loiane Gronner William Grasel Alvaro Camillo Neto Large companies using and supporting Perhaps the most notorious is Google, the official maintainer of the framework. The company has several products built using Angular and in recent years has been further supporting the development and evolution of the tool. An important point when choosing a framework is knowing which large companies are using it, because it gives us a signal that that tool will have support for updates and evolution since no one likes to keep rewriting products from scratch, here I will mention some global companies that use it Angular in your products, websites, web services: Google Firebase Microsoft Mercedes Benz Santander Dell Siemens Epic Blizzard's On the national scene we also have examples of large companies using the framework successfully, we can mention a few: Unimed Cacau Show Americanas Checklist Fácil Picpay Want to know more? Interested in starting with Angular?  

Architectural Model: how to choose the ideal one for your project


Architectural Model: how to choose the ideal one for your project

What is an Architectural Model and why is it important? Basically, an architectural model is the abstract structure on which your application will be implemented. “The software architecture of a program or computer system is the structure or structures of the system that encompasses the software components, the externally visible properties of those components, and the relationships between them.” (Bass, Clements, & Kasman, Software Architecture in Practice) To define the model that will best suit your project, we need to know well the company's short, medium and long-term strategies, the software's non-functional and architectural requirements, as well as the user growth curve over time and the volume of requests. As well as the points mentioned throughout this article, there are still others to take into account when deciding which architectural model to apply. As an example, we can list: Security concerns; Data storage; Lockins; Total volume of users; Volume of simultaneous users; TPS (transactions per second); Availability plan/SLA; Legal requirements; Availability on one or more types of platforms; Integrations. The survey of architecture, RAs (architectural requirements), VAs (architectural variables), RFs (functional requirements), RNFs (non-functional requirements) and the criteria that define each of these items directly influence the choice of the correct model. The choice of architectural model can impact the entire life cycle of the application. Therefore, this is a subject that we must treat with great attention. The use of MVPs (especially those that do not go into production) can greatly help with this task. They give a unique opportunity to make mistakes, adjust, make mistakes again, prove concepts, adjust and make mistakes as many times as necessary so that in the end the software has the architecture in the most correct version, thus bringing the true gains of this choice. How the architectural models are divided It is ideal to make it clear that like many definitions in the software world, what architectural models are and what they are can vary. Therefore, in this article I tried to divide them into four large groups: monolithic, semi-monolithic (or modular monolith), distributed monolith (or microlith) and microcomponentized. Monolithic Model in which all components form a single application or executable integrated into a single source code. In this case, it is all developed, deployed and scaled as a single unit. Figure 1 – Example of a Monolithic Model. Pros Simplicity: As the application is treated as a single, cohesive unit, it becomes simpler as all parts are contained in a single source code. Greater adherence to Design Patterns: taking into account that we have a single source code, another factor that makes it easier is that the design patterns themselves (Design Patterns, 01/2000) were written in times of monolith dominance, making the application of even more adherent. Greater performance: due to low latency in communication, monoliths tend to have good performance, even using more outdated technologies. Lower resource consumption: low complexity, simplicity and lower communication overhead between layers favor lower resource consumption. Easier troubleshooting: Creation of development and debug environments is made easier in monoliths, as the components share the same processes in them. Another factor that we can take into account is that monoliths have fewer external failure points, simplifying the search for errors. Cons Limited team size: breakdowns related to Continuous Integration and merge conflicts happen more regularly in monoliths, creating difficulties in parallel work for large teams. Scalability: Scalability may be limited in certain aspects. Even with ease in vertical scalability, horizontal scalability can often become a problem that could affect the growth of the application. Availability of windows: normally, for a monolith, executables are exchanged, which requires a window of availability without users accessing the application, which does not happen with other architectural models that can use other deployment techniques such as Blue-Green or even work with images or pods. Single technology: low technological diversity can often become an impediment to the growth of the application by only serving one type of operating system, for example, or not fully meeting new features requested by customers due to not having updates that have the capacity to solve complex problems. Greater expenditure on compilation and execution: large monoliths generally take a long time to compile and execute locally, generating a greater commitment in development time. When to Use Low Scalability and Availability: if the application has a limited scale where, for example, the number of users is low or high availability is not mandatory, the monolithic model is a good solution. Desktop Applications: the monolithic model is highly recommended for desktop applications. Low seniority teams: monolithic models, due to their simplicity and location of components, enable low seniority teams to work with better performance. Limited resources: for a limited infrastructure with scarce resources. Semimonolithic (or Modular Monolith) Model in which applications are composed of parts of monolithic structures. In this case, the combination tries to balance the simplicity of the monolithic model and the flexibility of the microcomponentized model. Currently, this architectural model is often confused with microservices. Figure 2 – Example of a Semimonolithic Model. Pros It brings benefits of the monolithic and microcomponentized models: with this, it is possible to maintain parts as monolithic structures and only microcomponentize components that have a real need. Technological diversity: possibility of using different technological approaches. Diversified infrastructure: this model can be developed to use both On-Premise and Cloud infrastructure, favoring migration between both. Supports larger teams: the segmentation of components allows several teams to work in parallel, each within its own scope. Technical Specialties: due to segmentation, the team's hard skills are made better use of, such as frontend, UX, backend, QA, architects, etc. Cons Standardization: due to the large number of components that can appear in a semi-monolithic model, standardization (or lack thereof) can become a major problem. Complexity: the complexity inherent to this type of model also tends to increase with new features. Therefore, new features such as messaging, caching, integrations, transaction control, testing, among others, can add even more complexity to the model. Budget: in models that support the use of different technologies with large teams, more specialist professionals with a higher level of seniority are needed, often resulting in greater expenditure on personnel expenses. Complex troubleshooting: the complexity of the model and the diversity of technologies make troubleshooting the application increasingly difficult. This is due to the large number of failure points (including external to the application) that come to exist and the communication between them. When to Use Accepted in Various Scenarios: it is a flexible model that can meet various scenarios, but not always in the best way. Little Definition: in projects that have uncertainties or even that do not have the full definition of their requirements, this model is the most suitable. In medium and large teams: as mentioned, the division of components into several groups facilitates parallel work in medium and large teams. Typically, groups have their own code repositories, which makes parallel work more agile. Diverse Seniority: this model benefits from teams with this format, as semi-monolithic software presents varied challenges, both in the frontend and backend layers and in infrastructure issues (IaC – Infrastructure as a Code). Infrastructure: for a Cloud-based or hybrid infrastructure, this model is more applicable. It is a model that allows, for example, gradual adoption between On-Premise and Cloud, facilitating adaptation and minimizing operational impacts. Distributed Monolith This modeling is a "modern" modeling that has also been implemented and confused with the microcomponentized/microservices model. "You shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile." (Fowler, Martin. 2015) In summary, in this architectural model the software is built on the basis of the monolithic model, but implemented according to the microcomponentized model. Currently, many consider it an antipattern. Figure 3 – Example of Distributed Monolith Model. It wouldn't be worth listing the pro features (I don't know if there are any), but it's still worth mentioning features that go against it: this architectural model brings together the negative points of the other two styles with which it is confused. In it, services are highly coupled and also have various types of complexity, such as: operational, testability, deployment, communication and infrastructure. The high coupling, especially between backend services, brings serious difficulties in deployment, not to mention the significant increase in points of failure in the software. Microcomponentized Software model in which all components are segmented into small, completely decoupled parts. Within microcomponents, we can mention: Microfrontends Microdatabases Microvirtualizations Microservices Microbatches BFFs APIs Figure 4 – Example of a Microcomponentized Model. "A microservice is a service-oriented application component that is tightly scoped, strongly encapsulated, loosely coupled, independently deployable, and independently scalable" (Gartner, n.d.). Opinions converge to say that every microservice that worked was first a monolith that became too big to be maintained and reached a common point of having to be separated. Pros Scalability: Scalability in this model becomes quite flexible. Depending on the need, the components are scaled in a specific way. Agile Development: Teams can work independently on each component, facilitating continuous deployment and accelerating the development cycle. Resilience: if a component fails, it does not necessarily affect the entire application. This improves the overall resilience of the system. It is important to note that there are single point of failure approaches to avoid this type of problem. Diversified Technology: each component can be developed using different technologies, allowing the choice of the best tool for each specific task. Furthermore, it also favors the existing skills of each team. Ease of Maintenance: changes to one component do not automatically affect others, facilitating maintenance and continuous updating. Decoupling: components are independent of each other, which means that changes to one service do not automatically affect others, facilitating maintenance. Cons Cost: high cost of all components of this model (input, output, requests, storage, tools, security, availability, among others). Size: microcomponentized software tends to be larger in essence. Not only the size of the application, but the entire ecosystem that permeates it from commit to the production environment. Operational Complexity: there is an exponential increase in complexity in this model. Designing good architectural components so that this complexity is managed is of great importance. It is important to choose and manage logging tools, APM and Continuous Monitoring, for example, well. Managing many microservices can be complex. Additional effort is required to monitor, orchestrate, and keep services running. Latency: Communication between microservices can become complex, especially in distributed systems, requiring appropriate communication and API management strategies. Network Overhead: Network traffic between microservices can increase, especially compared to monolithic architectures, which can affect performance. Consistency between Transactions: Ensuring consistency in operations involving multiple microservices can be challenging, especially when it comes to distributed transactions. Testability:  Testing interactions between microservices can be more complex than testing a monolithic application, requiring efficient testing strategies. Infrastructure: You may need to invest in robust infrastructure to support the execution of multiple microservices, including container orchestration tools and monitoring systems. Technical Dispersion: at this point, we can say that there is an action of "Reverse" Conway's Law, as teams, as well as technologies and tools, tend to follow dispersion and segregation. In teams, each person becomes aware of a small part of a larger whole. This way, for technologies and tools, each developer uses the framework or tools that suit them best. Domain-Driven Design: to increase the chances of success of this model, teams must have knowledge of DDD. When to Use Volumetrics: the microservices/microcomponents architecture has proven to be effective in high-volume systems, that is, those that need to deal with large amounts of transactions, data and users. Availability: one of the main reasons for adopting this type of architecture is availability. When well constructed, software that adopts microcomponentization does not tend to fail as a whole when small parts present problems. Therefore, other components continue to operate while the problematic component recovers. Scalability: If different parts of your application have different scalability requirements, microservices can be useful. You can scale only those services that need the most resources, rather than scaling the entire application. Team Size: Small teams can be problems. Configurations, boilerplates, environments, tests, integrations, input and output processes. Resilience > Performance": in cases of uncertainty, for example, the volume of requests and how far it can reach, such as large e-commerces in periods of high access (Black Friday) where it is necessary for the software to be more resilient and perform better median. Comparative Checklist Figure 5 – Checklist Comparison between models. Conclusion In summary, the choice of the architectural model is crucial to the success of the project, requiring a careful analysis of needs and goals. Each architectural model has its advantages and disadvantages and we must guide the decision by aligning it with the specific requirements of the project. By considering company strategies, requirements and architectural surveys, it is possible to make a decision that will positively impact the application life cycle. The work (and support) of the architecture team is extremely important. It is also of great importance that management and related areas support by providing time to collect this entire range of information. Still in doubt? At first, start with the modular semi-monolith/monolith. Likewise, pay close attention to database modeling. References Gartner. (n.d.). Microservice. Retrieved from Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994) Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. Bass, L., Clements, P., Kazman, R. (2013) Software Architecture in Practice (3rd ed.). Addison-Wesley. Microservices Architecture (12/2023). Retrieved from Fowler, S. J. (2017) Production Ready Microservices. Novatec. ArchExpert Training. (n.d.). Premium Content. Retrieved from Monolith First (06/2015). Retrieved from Microservices. Accessed on 01/2024.

Multi-brand design systems: what they are and main benefits


Multi-brand design systems: what they are and main benefits

What are multi-brand design systems Multi-brand design systems are systems with attributes that make them flexible for use in different contexts, visual patterns and interface design. They are developed for cases in which a single library aims to serve products from different brands. Generally, this type of design system is also independent of frameworks, platforms or technologies — they are called tech-agnostic design systems. Currently, the most popular agnostic design system is Lightning, developed by Salesforce, also the creator of the concept. Benefits In addition to being a single source of truth, the multi-brand design system shares the cost of operation, making work truly collaborative between teams. According to Volkswagen group designers, the implementation of GroupUI brought the following results: Increased agility, efficiency and cost reduction are some of the benefits of multi-brand design systems. Scalability Developed based on the concept of design tokens, they enable the same library to be replicated in different products, regardless of the framework in which they are developed. At the same time, they allow each of these products to use their own visual standards. Another very relevant point is the sharing of characteristics such as good practices, responsiveness, accessibility, performance, UX and ergonomics. Use in different technologies Currently, it is common to find in design systems, even those that serve a single brand, different libraries for web, iOS and Android products. This is due to the existence of different specifications for desktop and mobile browsers, as well as between devices with native operating systems, such as Apple and Google. Working independently of these technologies, it is possible to instantiate the same design system in different library components to meet these particularities. Gain in efficiency According to data released by UX and design systems leaders at the Volkswagen Group, through the presentation Multibrand Design System within the Volkswagen group & its brands, there is a great increase in agility, productivity and efficiency when working with the multi-brand concept . Operational efficiency with the use of multi-brand design systems. (Source: YouTube) Comparing the effort required between a product without a design system, going through one that has its design system, and arriving at one that adopts the multi-brand methodology, it is possible to notice an incremental and considerable reduction in UI efforts ( interface design) and development. This implementation enables a way of working that is more oriented towards user experience and discovery, by freeing up resources for these activities, which until then were being consumed in the design and implementation of interfaces. Standardization A detailed and well-specified design system becomes a single source of truth. When shared within the organization, in addition to making the work of teams much easier, it enables consistent standardization, avoiding the need for the same discussions, discoveries and definitions, which become ready to be reused as a result of the constant development of a design system. Easy customization According to experts, the main characteristic of a multi-brand design system is flexibility. In this context, making customizable means allowing each product to apply its visual design decisions. To make this possible, token design libraries are created. They can be easily duplicated and customized, generating distinct visual patterns for each brand and product. Design tokens can be interpreted as variables that carry style attributes, such as a brand color, which, applied as a token, allows, when changing the value carried by the variable, to reflect the change in all places where the color is displayed on the interface. In the example above, we have brand color specifications for three different design systems, and in the left column we have the token, which will remain the same across all products. The value carried by the variable is different in each case. These definitions apply to any other visual attribute, such as typography, spacing, borders, shading and even animations. Structure of multi-brand design systems According to Brad Frost, one of the most influential design systems consultants today and author of the book Atomic Design, it is recommended that multi-brand design systems have three layers: Three-level structure of a design system. (Source: Brad Frost) Tech-agnostic (1st layer) The agnostic level of a design system is the basis for the others, therefore, it only includes html, css and java script codes, with the aim of rendering components in the browser . This layer is extremely important in the long term, as it allows the future reuse of a design system. For example, in the current scenario, it can be said that the most popular language is React. However, this was not always the case and it is not known which technology will be the next to stand out. For this reason, it is important to have a base layer, which can be applied to new technologies, without having to start a new design system from scratch. In this first layer, designers and developers build the design system components in a workshop environment, documented in a tool such as Figma and Zeroheight. The result of this work are components rendered in the browser, considering that the framework adopted today may not be the same as the one adopted in the future. Tech-specific (2nd layer) The technology-specific level is where there is already a dependency on some technology and/or platform and, in addition, there is the opportunity to generate a design system layer for all products that use the same technology. A good example of this type of design system is Bayon DS, which serves SAJ products. It is also possible to use it to develop any other product that uses React technology. Prod-specific (3rd layer) The third layer is where everything becomes very specific and all the effort is made for a particular product. At this level, documentation can be created relating to very unique standards that only apply to that particular context. Following the Atomic Design concept, this layer creates components with greater complexity and less flexibility, such as pages and templates, in order to generate product patterns. In the third layer, individual applications consume the specific version of the selected technology, via package managers such as npm and yarn. How we are putting these new concepts into practice A few months ago, after the announcement of the Inner Source initiative, we began studying a way to transform Bayon, so that it could "receive" this new concept. Personally, I began in-depth research into the topics discussed in this article. Furthermore, my managers gave me the opportunity to participate in an advanced bootcamp on design systems, which brought me a lot of learning. In parallel to the research, we brought together some professionals with knowledge of Bayon, represented by colleagues from the architecture and product design teams of the JUS verticals, to discuss the possibilities of action to convert our design system to the most recent standards. Together, we diagnosed the most correct way to create and apply a design token library, allowing us to remove our current framework, Material UI, so that, in its place, there is the implementation of Softplan's new agnostic design system. Web components and Stencil Through recurring meetings with representatives of Softplan Group companies, the possibility of developing a library of web components is discussed. In it, each visual attribute or design decision is applied through design tokens, allowing complete customization that guarantees that each component will present the visual characteristics of the corresponding product. Web components are a set of APIs that allow the creation of custom, reusable and encapsulated HTML tags for use in web pages and applications.

Softplan is recognized by the Top Marketing and Sales Award with Construsummit 2023


Softplan is recognized by the Top Marketing and Sales Award with Construsummit 2023

Softplan was recognized with the Top Marketing and Sales Award, in the “Technology” category, for the case of Construsummit 2023 – the largest management and technology event focused on the construction industry held in September, in Florianópolis. Organized by the Association of Sales and Marketing Directors of Brazil (ADVB/SC), the award recognizes companies from Santa Catarina for cases and innovative marketing strategies with positive sales results. This year, the 37th edition of the award featured 16 winning projects, distributed in the retail, technology, services, communication, industry and micro and small enterprises (MSE) categories. “It is very gratifying to receive this recognition from an entity like ADVB/SC, as Construsummit is an event prepared by all Softplan employees and having this as one of our results demonstrates the size of our commitment and our impact on the industry of construction”, says Ionan Executive Director of Softplan for the Construction Industry. Held by Sienge, Construmarket, CV CRM, Prevision, Refera, Collabo and eCustos solutions, the fifth edition of Construsummit was attended by around 1.500 people from all regions of Brazil, including 700 C-Levels, as well as managers and representatives from the main entities of the sector. “In the two-day event, we promoted the largest networking network between civil construction agents ever created, resulting in more than 2,2 potential new business opportunities between group companies and members of the ecosystem”, highlights the executive. Softplan announced that the next edition of the event has already been confirmed for September 2024, with the expectation of receiving 2 thousand participants. To follow more details about Construsummit 2024, visit the official website.

André Tavares, Softplan's new CFO, must prepare the company for entry into the capital market


André Tavares, Softplan's new CFO, must prepare the company for entry into the capital market

André Tavares de Andrade has over 15 years of experience in the area and, before assuming his new position, as the company's new Chief Financial Officer (CFO), he was financial vice-president of Anima Educação, leading the areas of treasury, controllership and investor relations. One of the factors that attracted the new CFO to the Softplan Group was the growth and transformation project, with a strong role in the technology sector in Latin America. “It is a solid, long-standing company with a high reputation that seeks to take a new leap in terms of growth and continuous evolution in governance, combined with the founders’ vision of perpetuating the company and tireless innovation”, highlighted the executive. See the full report on Pipeline here.

Softplan and clients come together to build the future of Public Ministries together


Softplan and clients come together to build the future of Public Ministries together

On October 19th and 20th, Softplan promoted the VI Public Ministry Strategic Forum in Florianópolis. This year, 25 representatives from eight institutions in the segment met with managers and technicians from the company to discuss the development of the SAJ Ministérios Públicos solution. In its sixth edition, the meeting had the motto: “Building the future of MPs together”. “This event is already a tradition and is increasingly gaining momentum. And for a simple reason: to develop the solution together with customers, working together. Then we will have two days of sharing information, best practices and experiences. Working together with the Public Ministries is a commitment from Softplan”, said Softplan CEO, Eduardo Smith. The two days of the MPs' Strategic Forum totaled more than 15 hours of programming, see details in the full report here.

Be a softplayer

Work at one of the largest software development companies in Brazil, which values its team with partnership and autonomy.

Image be softplayer
Discover the Visão Softplan portal, our new content hub about business and technology! Click here