When I was hired into an experimental no-code software developer team, we realized little was written about how a group of no-coders operate together day-to-day. Without the guidance of best-practices, we had a heck of a time trying various things (with varying levels of success).

‍

Let’s reflect on a few areas, and hopefully this helps a new no-code department set up some scaffolding for productivity:

‍

1. Areas of responsibility: frontend, backend, custom code, team lead.
   ‍
2. Tech stack: Bubble, Make, custom code.
   ‍
3. Collaborating with each other: branching, merge process, work distribution.
   ‍
4. Collaborating with custom-code devs: examples of requests we made.
   ‍
5. Cons of speed: erroneous features, quantum utility.

‍

1 / No-code is wonderful in that every dev is “full stack” out-of-the-box; a single no-coder ships fully functional web apps. This introduced a unique challenge — roles got messy as multiple no-code devs contributed into the same project, stalling our decision-making.

‍

The areas of responsibility (AORs) for a no-code web app dev team turned out to be:

‍

• Frontend: ui standards, ui component library, reusable elements, aesthetic cohesion across pages, ux decisions.
  ‍
• Backend: data model, search logic optimization, option sets, workflows, custom events, privacy settings, API connectors, logins.
  ‍
• Custom code: HTML / CSS components, JavaScript workflows, custom plugins, troubleshooting API connections.
  ‍
• Team lead: feature prioritization, plugin auditing, merge conflicts, quality assurance testing on main version, deploying to live, usability testing.

‍

Reflecting back, we should’ve assigned one (or more) AOR to specific people such that they would have the final say in relevant discussions, and rotated these AOR assignments as needed.

‍

2 / Although there’s an abundance of no-code tooling out there, we had a relatively simple tech stack for the majority of day-to-day software development.

‍

• Bubble: This was our daily driver for all web app development. Out of the box it came with drag-and-drop editors for user interface / database / rules engine / job scheduling / deployment. Functionality was extended through Bubble’s plugin marketplace. We were on Bubble’s agency pricing plan.
  ‍
• ‍Make: Bubble’s API connection functionality was limiting and extract-transform-load was non-existent, so Make was used to send / receive / transform data with other services. We also had success with Zapier and Xano, but Make had a favorable user experience.
  ‍
• ‍Custom code: JavaScript / HTML / CSS was used wherever Bubble plugins fell short (eg. custom API calls, iframe embeds, communication between window objects, etc).

‍

‍

3 / With DevOps “outsourced” to Bubble, there’s continuous deployment of every frontend and backend change. Bubble’s perpetual “please refresh the page” alerts became the bane of existence.

‍

We religiously used Bubble’s version-branches. Typically, devs would create (and merge) their branch every few days delivering their atomic unit of work.

‍

Merging would be communicated over Slack — to give a heads up around merge conflicts — and every dev unit-tested their changes in the main trunk version (or rolled back the version if testing proved unsuccessful).

‍

Finally, we had to get intentional about work assignments. No two devs could work on the same page. Ideally, devs worked on separate pages. Alternatively, one dev focused on reusable elements while another enhanced a page.

‍

‍

4 / Access to a senior custom-code software developer proved transformational to our no-code projects. Specifically, we stopped encountering feature requests that were beyond our reach.

‍

The custom-code dev team was a separate department (with different priorities). We didn’t have full-time support, so instead we made adhoc support requests — a few examples:

‍

• Slackbot API integration: We had a feature which prompted people to answer some questions within Slack. A chat with our custom-code dev made quick sense of Slack’s API documentation and sorted out the API data payload structure needed for the Bubble app.
  ‍
• ‍Enhancing a Bubble plugin: A Bubble plugin developer released a rich text editor using the TipTap library. TipTap had a collaborative-editing mode, but it wasn’t included in the original plugin release. Our custom-code dev shared some code snippets with the Bubble plugin developer to enable that functionality, and it became available in the plugin’s next release allowing us to support a stakeholder’s wish-list product feature.
  ‍
• ‍Notion authentication: We had a feature which embedded our Bubble app as a form within a Notion page, and created Notion database records as that form was completed. Our custom-code dev took a few days to figure out the OAuth login (ie Notion credentials) for the Bubble app’s API workflows to send data to the correct Notion table.

‍

‍

5 / If you’re a Bubble developer reading this, you already know how quickly features ship. It took us some time to find our collaborative groove, but eventually we learned that a team of Bubble devs ship even faster.

‍

Sometimes too fast. A common challenge we faced is that our delivery would outpace the scheduling of feedback sessions. Sometimes this meant development would go in the wrong product direction and would need to be frustratingly reverted.

‍

We never found an ideal solution for this. One approach proved helpful by scheduling adhoc usability testing sessions as soon as some quantum of utility was delivered.

‍

I wouldn’t be surprised if web app development becomes progressively low-code, where common features get delivered by no-code devs, while custom-code devs focus exclusively on novel functionality.

‍

Takeaway:

A new no-code department should be aware of productivity vs speed.