RunMyProcess Easy Builder

No-Code Platform BPM Workflow Design Studio

JQuery

SaaS

BPM

Drag-and-Drop

Designed and built a no-code drag-and-drop application builder that reduced custom form development time from 4 weeks to 1 hour. Easy Builder enabled non-technical presales professionals to create production-ready business applications during client meetings, becoming a key market differentiator for RunMyProcess.

Jun 1, 2017

Green Fern
Green Fern
Green Fern
Role

Product Owner & Senior Frontend Developer

Product Owner & Senior Frontend Developer

Product Owner & Senior Frontend Developer

Duration

3 years (2014-2017)

3 years (2014-2017)

Team

2 frontend developers, 1 backend developer, UX designer, product manager

2 frontend developers, 1 backend developer, UX designer, product manager

Tech

jQuery → React (migration), Node.js, HTML5 Drag & Drop API, Redux, JSON-based persistence

jQuery → React (migration), Node.js, HTML5 Drag & Drop API, Redux, JSON-based persistence

The Problem

RunMyProcess sold BPM (Business Process Management) software to enterprise clients. The sales cycle had a critical bottleneck:

Presales demonstrations required custom development:

  • Creating demo applications took 4+ weeks of developer time

  • Presales team couldn't customize demos for client-specific needs

  • Lost deals because competitors showed working prototypes faster

  • Developers became bottleneck for sales team

The opportunity: If presales could build applications themselves, RunMyProcess could:

  • Prototype client solutions during meetings

  • Iterate in real-time based on feedback

  • Close deals faster with working demos

  • Free developers to focus on product features

The constraint: Presales professionals weren't developers. The tool had to be:

  • Visual and intuitive (drag-and-drop)

  • No code required

  • Production-quality output

  • Fast enough to use in client meetings

The core challenge: How do you build a tool that lets non-developers create enterprise applications without writing code?

My Approach

1. User Research with Presales Team

Spent 2 weeks shadowing presales:

  • Observed client demos and pain points

  • Identified most common application patterns

  • Documented what presales needed vs. what developers built

  • Created personas for "citizen developers"

Key insight: Presales thought in terms of "what users see" (forms) and "what happens" (workflows), not technical implementation.


2. Two-Pane Design Philosophy

Designed around the mental model of presales users:

Left pane: What users see (Interface Designer)

  • Visual form builder

  • Drag widgets onto canvas

  • Configure appearance

Right pane: What happens (Workflow Designer)

  • Visual workflow builder

  • Connect process steps

  • Define business logic

This matched how presales described applications: "Users fill out this form, then this approval happens."


3. Widget-Based Architecture

Created a library of pre-built widgets:

  • Text inputs, dropdowns, date pickers

  • Tables, grids, file uploads

  • Custom components for common patterns

Each widget:

  • Configurable via properties panel

  • Generates clean HTML/CSS

  • Connects to workflow engine

  • Validates data automatically


4. Iterative Prototyping

Built 5 increasingly complex prototypes:

  • Prototype 1: Static mockup (validate concept)

  • Prototype 2: Basic drag-and-drop (prove technical feasibility)

  • Prototype 3: Form builder only (test with presales)

  • Prototype 4: Add workflow engine (validate end-to-end)

  • Prototype 5: Production MVP (beta with real clients)

The solution

Interface Designer

Visual form builder with drag-and-drop interaction:

Widget Library (left sidebar):

  • Input widgets (text, number, date, dropdown)

  • Layout widgets (container, tabs, accordion)

  • Display widgets (label, image, table)

  • Advanced widgets (file upload, signature, maps)

Design Canvas (center):

  • Drop zone for widgets

  • Visual editing (resize, reposition)

  • Property inspector for configuration

  • Preview mode to test behavior

Properties Panel (right):

  • Widget-specific configuration

  • Data binding to workflow

  • Validation rules

  • Styling options


Workflow Designer

Visual workflow orchestration connecting process steps:

Workflow Steps:

  • Human tasks (approvals, reviews)

  • Service calls (REST APIs, database queries)

  • Business rules (conditions, calculations)

  • Notifications (email, SMS)

Visual Flow:

  • Drag workflow steps onto canvas

  • Connect with arrows to define sequence

  • Configure step parameters

  • Test workflow execution


Two-Way Binding

The magic: changes in Interface Designer automatically reflected in Workflow Designer and vice versa:

  • Add form field → Available in workflow as variable

  • Create workflow output → Can be displayed in form

  • Modify data model → Both views update


JSON-Based Persistence

Applications saved as JSON configuration:

{
  "interface": {
    "widgets": [
      {
        "type": "textInput",
        "id": "employeeName",
        "label": "Employee Name",
        "required": true,
        "validation": "^[A-Za-z\\s]+$"
      }
    ]
  },
  "workflow": {
    "steps": [
      {
        "type": "humanTask",
        "name": "managerApproval",
        "assignee": "manager",
        "form": "approvalForm"
      }
    ]
  }
}

This meant:

  • Applications are data, not code

  • Easy to version control

  • Export/import between environments

  • Extend via configuration, not custom development


Technical Implementation


Architecture Evolution

Phase 1: jQuery (2012-2013)

  • Started with jQuery and jQuery UI

  • Drag-and-drop with jQuery UI Sortable

  • DOM manipulation for rendering

Why jQuery initially:

  • Fast to prototype

  • Mature drag-and-drop libraries

  • Team expertise

Why we migrated:

  • jQuery couldn't scale to complex applications

  • DOM manipulation became unmaintainable

  • State management was chaotic

  • Performance issues with large forms

Phase 2: React Migration (2014)

  • Rebuilt with React and Redux

  • Component-based architecture

  • Declarative rendering

  • Predictable state management

Why React:

  • Component model aligned with widget architecture

  • Virtual DOM solved performance issues

  • Redux made state predictable

  • Easier to test and maintain


Widget Architecture

Every widget followed this pattern:

class TextInputWidget extends React.Component {
  render() {
    const { label, required, value, onChange } = this.props;
    
    return (
      <div className="widget-container">
        <label>
          {label}
          {required && <span className="required">*</span>}
        </label>
        <input
          type="text"
          value={value}
          onChange={onChange}
          required={required}
        />
      </div>
    );
  }
}

Widget Registry:

  • Central registry of available widgets

  • Widgets self-describe their properties

  • Drag-and-drop creates widget instances

  • Properties panel generated from widget schema


Drag-and-Drop Implementation

Used HTML5 Drag & Drop API with React:

// Simplified drag-and-drop logic
const handleDragStart = (e, widgetType) => {
  e.dataTransfer.setData('widgetType', widgetType);
};

const handleDrop = (e) => {
  const widgetType = e.dataTransfer.getData('widgetType');
  const newWidget = createWidget(widgetType);
  dispatch(addWidget(newWidget));
};

Challenges:

  • HTML5 drag-and-drop API is inconsistent across browsers

  • Had to add polyfills for IE support

  • Touch devices required separate implementation


State Management with Redux

Application state structure:

{
  interface: {
    widgets: [...],
    layout: {...},
    selectedWidget: null
  },
  workflow: {
    steps: [...],
    connections: [...],
    variables: [...]
  },
  preview: {
    mode: 'design' | 'preview',
    testData: {...}
  }
}

Impact & Results

Quantitative Impact

4 weeks → 1 hour development time

  • 75% reduction in custom application development

  • Presales became self-sufficient

  • Developers freed for product work

100+ applications built with Easy Builder in first year

  • Customer onboarding applications

  • Approval workflows

  • Data collection forms

  • Internal tools

50% increase in presales productivity

  • More demos per week

  • Faster iteration with clients

  • Higher close rates

4 weeks faster sales cycles

  • Working prototypes in first meeting

  • Real-time customization during demos

  • Client confidence from seeing working software

Qualitative Impact

For presales:

  • Empowerment to create without developers

  • Confidence to promise custom solutions

  • Ability to iterate with clients in real-time

For clients:

  • Saw working software immediately

  • Could request changes during meetings

  • Confidence RunMyProcess understood their needs

For developers:

  • No more rushed demo requests

  • Focus on product features

  • Created reusable widgets used by presales

For the company:

  • Market differentiation ("build apps in minutes")

  • Competitive advantage in sales

  • New revenue from citizen developer market

Key Learnings

What Worked

User research with presales paid off The two-pane mental model came from observing presales. Building what they described, not what we assumed.

Widget abstraction was right level Not too low-level (code), not too high-level (templates). Widgets gave flexibility with guardrails.

React migration was worth the pain Migrating mid-project was risky but necessary. React's component model was perfect for widgets.

JSON persistence was genius Applications as data meant we could version, export, extend without code changes.


What I'd Do Differently

Start with React We knew jQuery wouldn't scale but started there anyway for speed. Starting with React would have saved the migration pain.

More automated testing We relied too much on manual testing. Automated widget tests would have caught regressions faster.

Better widget documentation Presales figured out widgets through trial and error. Better docs and tutorials would have accelerated adoption.

Performance optimization sooner Large forms were slow. Should have profiled and optimized rendering earlier.


Challenges Overcome

Balancing power vs. simplicity: Presales wanted easy tools; developers wanted flexibility. Widgets struck the right balance.

Browser compatibility nightmares: IE8/9 support was brutal. Polyfills and progressive enhancement saved us.

Managing scope creep: "Just add this widget" requests were constant. Widget registry architecture made it manageable.

Key Takeaway

No-code tools succeed when they match users' mental models. Easy Builder worked because it reflected how presales thought about applications (forms + workflows), not how developers build them (code). The widget architecture provided the right abstraction layer, powerful enough for complex apps, simple enough for non-developers. This case study demonstrates product ownership, technical architecture decisions (jQuery → React migration), and building for non-technical users.

Create a free website with Framer, the website builder loved by startups, designers and agencies.