Ed Montalbano

Software Engineer & Design Specialist

Engineering a different caliber of software.

Elevating software with the right tools, processes and mindset.

Some Examples of My Work

Aeronautis Application Builder

Aeronautis is my response to a real problem in the software world. It is difficult for non-developers to describe what software needs to be built. Software takes a long time to build, and the problem custom software tries to solve is a moving target. These three problems combine to form a series of common problems. Projects go over budget. They do not solve the root problem. Only the most critical systems can be maintained for a reasonable amount of time.

Aeronautis allows non-developers to participate in the build. It gives anyone the tools to design, prototype, and iterate on fully functioning applications. Aeronautis applications export to source code. Stakeholders and developers can go back and forth, building and tweaking applications. All in a matter of hours or days, instead of months or years.


View Model Expressions Language

View Model Expressions Language

The VME language is an experiement that has yielded great results. In lay terms, it's a small programming language that does all of the heavy lifting when it comes to working with data. Most applications receive data from the database. To display it on an interface, developers will typically need to make transformations to it. When the user interacts with the interface, additional transformations are needed. The VME language takes the most common transformations and either automates them or turns them into one liners. It also automates the process of getting data, saving data and keeping data fresh.

Common interactions like search, sorting and filtering are done right in VME and can be highly configured with simple changes. For example, searching data is "fuzzy" by default. That means that if the user has a typo in their search, the results they were looking for will still be returned. The search could be configured to be "strict" so that those results are not returned. Or they could be made "phonetic" so that the search is tailored towards searching for difficult to spell words like names or addresses.

If you're curious to hear more about the language in technical terms, I am always happy to chat about it. I believe this or something similar will be to frontend development what SQL was to backend development.


Query Builder

Writing queries is a highly speciailized skill. In order to enable non-developers to build custom applications, they must be able to write queries that describe what data they need. The Query Builder is an interface that can walk anyone through the process. Users start by selecting the type of data they will be querying. To select the fields, a modal is opened that helps the user make the right choices. Each field is shown in the middle column with its API name and data type. A table on the right shows samples of the data in each field. The same modal is used for selecting fields to filter by. As users build a where clause to filter data, a preview of the query's results gets updated.

If there is data that needs to be inferred in real time, users can use a syntax similar to Excel or Salesforce formulas to define "dynamic fields." For example, let's say we are building form for updating old records. A dynamic field called "Needs review" could be added which flags the records that are missing critical information. This "Needs review" field would be calculated in real time, update as the user is making changes to records, and would not need to be stored in the database.


Aer Components

Components are building blocks that enable faster development. On the surface, Aer components are not any different than Bootstrap, Tailwind, Shoelace or any other component library. Their difference lies in the problem that they were designed to solve. Typical component libraries are designed for developers to make modifications as they see fit. Aer components are designed to be fully customizable from configuration alone. They can still be modified by developers. In most cases, developer modification isn't necessary.

Each component comes with one or two sets of options variants. For example, buttons have one set of variants that set the default styling properties. "Destructive" buttons have a red background and white text to indicate a destructive action. "Brand buttons" use the brand color to draw the user's attention to the button. Some components use two sets of options, like the "callout" component. One set of options is for describing the type of callout, like "info" or "warning". The other set of options controls the standard look and feel. If a chosen variation is close, but not quite right, the user or developer can make fine tune adjustments using the CSS variable system that defines all of the fine details of each component.

Design Showcase

Aeronautis Application Builder


Leave of Absence and Benefits Portal


Daily Standup Assistant


Project Management Portal

About Me

My wife, my two daughters and me My wife, my two daughters and me

My Story

How do people usually figure out what they want to do for a living?

I fell into software development by chance. I'm told I was always fascinated with taking things apart and figuring out how they worked. Luckily, my parents didn't discourage this, and just told me to make sure that when I take something apart I put it back together afterwards. Understanding how computers worked became what captivated me during my formative years.

I grew up with a computer, and around age 12 I got my first taste of programming when I started making computer games. They were not very good, but I had a lot of fun making them. By 15 I had built a flash gaming website and used it as a reference to begin doing freelance flash and php development.

It wasn't until my junior year of high school that I realized I could be building software for a living. One of my friends said, "so you're probably going to go to college for computer science, right?" I can say now — after 19 years of doing it — I couldn't imagine myself doing anything else.


My Development Philosophy

Infrastructure is an asset. Custom code is a liability.

This is a core principle I follow to ensure success at the macroscopic view. The weaker the infrastructure, the more a system must rely on customization. Then technical debt piles up. Developers leave. Critical knowledge of the system falls to a select few. Onboarding and knowledge transfers become more expensive. Few people have a broad understanding of the system, so bugs become more frequent. Fewer features can be shipped per cycle and putting out fires becomes the norm.

This is a common description of many software teams.

The story is different when a system has a stronger foundation to work from. Good infrastructure means less custom code needs to be written to accomplish a business directive. Less code means features can be built faster and teams aren't as afraid to prototype ideas. The investment in new features isn't so expensive that management teams let the sunk cost fallacy marry their business process to bad ideas. Developers are happier and stick around longer because their job isn't all late night firefighting and chasing down elusive bugs.

The type and level of infrastructure depends on what the system is. If infrastructure can be bought and serves its purpose well, then it is usally advisable. Additional infrastructure can always be built to support the system.

For example, CRM and ERP systems have quickly becoming the core of many businesses. It is rare for one of these systems to properly support the business out of the box. But before a team dives heavily into writing custom code for their system, thinking about infrastructure can save the team from significant headaches down the road.


Infrastructure vs Custom Code
Focus on what is important
Focus on what is important.

Creative types can be quick to work on self-satisfactory tasks, like dreaming up how things could be instead of moving the mission forward. Management types can be quick to find a nail-shaped problem and pull a hammer out of their favorite book of management. Meticulous people may demand that everything follows the "correct" way of doings things.

The path towards specializing in career skills can steer anyone towards a similar style of cargo cult behavior. We are enlightened to the fact that a style of problem exists in the world. We are taught a secret ritual that exercises the problem. Then, before you know it, performing the ritual becomes more important than solving the original problem.

I do not have any secret ritual to exercise the problem above. My best attempt at helping a team stay focused is to regularly step back and try to ask the right questions.


Balance the needs of everyone on the team.

I have seen death by meeting kill productivity and I have seen overly autonomous teams go off the rails. I have seen top-down decision making kill morale and I have seen process democratization lead to endless wheel spinning.

From the managerial and executive perspective, information must flow. There are real problems that have to be reacted to. Failure to do so in a timely manner is expensive and those expenses compound. To make matters worse, there is an unfortunate imbalance between problems and solutions. One where problems tend to have the most negative impact up the chain of command and solutions tend to have the most negative impact down it.

From the perspective of those in the trenches, a certain level of trust is needed. Everyone has a different style of working through problems, and the autonomy to do can be critical. Everyone has a different perspective on a problem, and top-down decision making can quickly demoralize a team by invalidating their perspectives. Someone whose job is to have meetings all day may not fully grasp the cost of interrupting someone whose job is to build a mental model of a problem and then solve it.

Collaborative Problem Solving

Interested in talking?

Send me an email or connect on LinkedIn

Open LinkedIn