Web development, software and applications to solve real needs.

PARTY POINT

First we need to know what problem we're solving.

A development project can start in many ways: a company needs a new website, wants to sell over the Internet, has a process that continues to do by hand or needs a tool that the solutions it currently uses do not cover.

Before we talk about languages, frameworks or platforms we want to understand that need. We review what you want to get, who will use the solution, what information you need, and whether you need to communicate with other systems.

With that context we can distinguish whether it is reasonable to develop something new, integrate tools that already exist or propose a simpler solution. If there is a simpler way to solve it, we prefer to raise it rather than add complexity that must be maintained later.

A SOLUTION WITH A CLARK SCOPE

Know what we're going to build before we start building it.

A corporate website, an online store and a management application have very different needs, so each project starts by defining what the solution should do and how far the work goes.

On a website it may mean deciding on the structure, contents, forms and calls to action. In an ecommerce catalog, payments, orders, shipments or synchronizations are also entered. In an application users, permissions, states, data, automations and integrations with other services may appear.

If a functionality requires an external API, license, access to an ERP or CRM, payment gateway or any third party service, it is taken into account before incorporating it into the project.

The proposal should make it clear what is to be developed, what the customer needs to validate it and what will happen after it is published.

FROM ANALYSIS TO DELIVERY

A process that you can follow without having to become a technician

We do not expect you to arrive with a specification document. You tell us how your business works, what you want to get and what problems you currently encounter. From there we take care of translating it into technical decisions.

1. Analysis

   We collect the information necessary to understand the project, its users and the main functions. If there is already a website, an application or a previous system, we review that starting point.

2. Proposal

   We define the scope and we propose how to resolve it. The proposal explains what will be done, what includes the project and what elements may depend on third parties.

3. Design and validation

   In the projects that require it, we prepare the structure and design before entering the main development phase. We review it with you before we approve it.

4. Development

   With the defined scope we started to build. We chose the technology according to the needs of the project, without forcing all the works to use the same tool.

5. Review

   Before publishing we show you the project running. We check the important routes and each function does what was expected, in addition to detecting pending adjustments.

6. Start-up

   Once approved, we take care of the deployment on the infrastructure managed by ManiaNetwork and leave the service ready to operate.

BEFORE ELECTING A TECHNOLOGY

Processes, people and data first

An application should not be designed around a nice screen without first understanding what happens behind it. If a company wants to digitize a process, we need to know who starts it, what data it uses, who should review it, and what happens next.

For example, "managing orders" can mean much more than saving a form. It can involve customers, products, stocks, states, permissions, notifications, documents or connections to other systems.

The same is true of a website. Before designing it, we need to understand what the company offers, what it is looking for and what action we want to facilitate: calling, asking for a quote, booking, buying or requesting information.

This way of working allows us to avoid unnecessary functions and dedicate development to what it really contributes to the project.

DISARMAMENT FOR REAL SITUATIONS

The project has to work outside the demo

During the development we convert the needs of the project into routes that we can check. What happens if a data is missing? What does a user see without permissions? What if an external service does not respond? How is it confirmed that an order has been registered?

They are less visible questions than the design, but they often determine whether a tool is comfortable when it starts to be used every day.

On a website we also review the project as a real person would use it: navigation, mobile, forms, content, load speed and ease to get to important information. We prefer to detect these problems before publishing.