What to Expect in Your First Month Working With a Solitude

Your first month with Solitude Infotech

Here is how we are laying down the foundation and architecture of your application.

Week one is the toughest, particularly on founders.

You're likely assuming that by Monday morning our engineers will be spitting out millions of lines of code by Friday afternoon. We don't operate that way. Trying to skip to code without establishing the perimeter of your application will only burn your runway to its very last bit.

For many years we fell victim to client desire for quick visual progress and we would push front end mocks out by the end of week two that hadn't been vetted by actual testing, in order to make it "come alive" during our zoom call, only to then have to spend three months rewriting what we already had because we didn't spend a week or two establishing our database schema and system logic.

We'll be establishing your system architecture and defensive guardrails in week one.

Weeks 1-2: The Logic Gantlet

Here we will map out your data structures and system dependencies. We'll figure out how data will be traveling to and from all points in your system whether this be a cross-platform mobile application (we like Flutter!) or complex lead scoring logic before we even get to writing controller functions.

For example, in our last campaign with a financial partner we were automating a lead aggregation funnel for GoHighLevel and although our client was impatient to get started building out her live intake forms, we knew we needed to spend 10 solid days mapping out her custom variables (like "loan_purpose_requested," "monthly_gross_income," "preferred_contact_window") and checking her web hook JSON was correctly formatted.

This is where we will build out the bedrock of your application and for any non-technical stakeholder this will appear slow; it is one necessary up front investment that will pay dividends in months of saved development down the line and preventable issues down the future.

Week 3: Deploying the Defenses

We don't push a bit of code manually, ever. A system can be only as reliable as the infrastructure that backs it. Anything that involves pushed binaries or manual uploads will always be vulnerable.

We will be deploying a CI/CD pipeline by week 3 that is automatically checking and pushing your code into containerized environments in our private DigitalOcean App Platform. Each and every piece of code pushed by our engineers to our Git repo will be checked for errors automatically before it gets pushed to the staging environment and available to your inspection on a live url.

Each feature a developer has coded and then checked for proper function and standards of quality by our Senior engineers will be pushed automatically to our staging environment and you can watch development from a distance on its own url without the need for weekly status updates.

Week 4: Building the heart of your App

We'll be focusing the fourth week of the project on the core functionality of the system. What we call, "the happy path," instead of a pretty U.I., complex user configuration options or small supplemental features, we'll focus on building out the technical engine that will execute your product's functions.

Whether it is an automated backend process or a custom n8n configuration and any other combination of integrations, we will pushing the boundaries with failure tests by sending malformed inputs through it, we'll see how it handles failed network connections to third party applications, and what our automated response to errors looks like on a local level network failure so we can ensure integrity of your transactional data.

We have found that contrary to much of modern software development processes that delivery of a feature that is completed and optimized is counterproductive to the delivery of sprint 1, which in the grand scheme of things will only introduce technical debt that only manifests once there are masses of real-time users interacting with your application.

It is the framework that we are building in this step; not the features it's executing.

This month do you want to ship a feature rich application with a solid backbone or something that looks pretty but is vulnerable on week 4?