This is part of a series I’m writing to inspire myself and other builders by shining a light on companies that ServiceNow has acquired. If you’re dreaming of building something yourself, these stories aren’t just history, they’re playbooks with lessons we can learn.

Today, we look at SkyGiraffe, a company that took on a challenge nearly every enterprise faces, and did it with clarity, conviction, and craft.

The Mobile Work Problem No One Was Solving (Well)

In 2012, nearly everyone still worked from the desktop.  I remember ServiceNow telling folks “use safari on the iPhone”.  Eventually they came around and set up what is now known as the “Classic Mobile” application.  Here’s a link I can find referencing wiki page on ServiceNow’s Mobile docs. 

SkyGiraffe saw this gap. Their insight was simple but powerful: employees needed real, secure access to business data on the go, without the traditional overhead of building mobile apps from scratch.

They didn’t just want to make mobile access easier, they wanted to make it fast, scalable, and native. For everyone.

The Founders Behind the Vision

SkyGiraffe was born from the experience and vision of Boaz Hecht and Itay Braun.

Boaz brought a rare combination of entrepreneurial grit (from his time leading ClubSMS and SRL Group) and consulting insight from Deloitte. His later role as VP of Platform at ServiceNow reflected his product-first mindset and belief in removing friction for users.

Itay came from a deeply technical background, including roles at Microsoft and startup leadership at TWINGO. He was a teacher, an architect, and a builder, equally comfortable in a data stack as he was explaining SQL to a room of learners.

Together, they formed a team that understood both the pain of enterprise software and the elegance needed to solve it.

What SkyGiraffe Built (and Why It Worked)

SkyGiraffe offered a no-code platform for delivering mobile apps that could tap into existing enterprise systems, Oracle, SAP, SQL, cloud, on-prem, you name it.

Using a "meta-data architecture," their platform auto-generated mobile applications directly from enterprise data structures and workflows. These apps worked natively on iOS and Android, supported offline access, and came with built-in capabilities like maps, contacts, notifications, and more.

No front-end coding. No heavy scripting. Just point, connect, and deploy.

In other words, they abstracted away the hardest parts of mobile enterprise development, and gave companies a way to build hundreds of apps quickly, securely, and beautifully.

The Acquisition: October 2017

ServiceNow acquired SkyGiraffe in October 2017. The move was part of a broader mobile-first push, following its acquisition of the design firm Telepathy just weeks earlier.

By integrating SkyGiraffe’s tech into the Now Platform, ServiceNow aimed to:

• Enable native mobile versions of every packaged app, starting with ITSM

• Let customers build apps in days, not months

• Offer offline support and native mobile experiences with zero code

As CJ Desai, ServiceNow’s Chief Product Officer, put it: “Our work lives should be as mobile-friendly as our consumer lives.”

SkyGiraffe helped make that possible.

What Lives On Today

While the SkyGiraffe name may no longer be on a website, its DNA lives on.

ServiceNow’s Mobile App Builder, Mobile Studio, and native mobile capabilities owe much to SkyGiraffe’s foundations. The speed, flexibility, and ease of delivering mobile experiences are now part of what people expect from the Now Platform, and SkyGiraffe was a huge leap forward in that direction.

Many of the team members, Boaz, Itay, Yev, played key roles in shaping ServiceNow’s mobile strategy during their time there.

What they are up to now?

Today Boaz Hecht together with two of the original SkyGiraffe team, Josh Russ & Yev Goldin joined forces start 8Flow.ai, proof that great teams often stick together and keep building

Itay Braun has since co-founded Metis which was just acquired in March of 2025 by Dynatrace. Metis, “Enabling developers to own their Database”.  They enabled development teams to proactively take a preventative and holistic approach to database code. 

What Modern Builders Can Learn

1. Solve a real pain with elegance.
   SkyGiraffe succeeded because they saw a painful problem (mobile access to enterprise data) and solved it simply, without compromising on enterprise-grade quality.

2. Your architecture matters.
   Their meta-data-driven approach didn’t just work, it scaled. Good architecture creates leverage and makes your product 10x more valuable in the right hands.

3. Design for the future, not the past.
   While others were focused on making legacy systems work a little better, SkyGiraffe designed for the mobile world that was coming. That’s what made them acquisition-worthy.

Final Thought

Acquisitions like SkyGiraffe aren’t just footnotes in a company’s history. They’re inflection points. They remind us that bold ideas, when paired with thoughtful execution, can shape the direction of entire platforms.

To all the builders out there: keep solving real problems. You never know where the next good idea might take you.

The Spark in the Conversation: What We Can Learn from ServiceNow’s Acquisition of Qlue

By a Builder, For Builders – A Series on What Past ServiceNow Acquisitions Teach Us About Innovation

In the spring of 2017, ServiceNow quietly made a move that would later become foundational to its journey into AI-powered service experiences: it acquired a small startup called Qlue for $6.6 million.

To many, this may have looked like a footnote. But for those of us who build things, especially in the enterprise space, it was anything but.

Qlue didn’t just build bots. It built conversations. And more than that, it built the idea that those conversations, once trapped in static FAQs, clunky portals, and long wait times, could finally flow.

Why Qlue Mattered

Founded by Hasan Rizvi (a veteran from Oracle with a deep well of enterprise software experience) and Rahim Yaseen (who’d helped architect platforms at Oracle, SAP, and Couchbase), Qlue was born in 2014 out of a clear, growing frustration: why did enterprise software feel so impersonal, so transactional, so… slow?

In an era where consumers were already chatting with Siri and Alexa, enterprise users were still submitting tickets like it was 1999.

Qlue set out to change that by building AI-powered virtual agents for the enterprise. Bots that didn’t just respond with static answers, but could hold conversations, ask clarifying questions, route users intelligently, and get work done. Think: asking HR about your parental leave policy, checking your order status with customer service, or diagnosing an IT issue, without ever opening a ticket.

They weren’t building novelty. They were building relief, at scale.

The Builders Behind It

What makes Qlue even more interesting to reflect on today is the caliber of builders it brought together. These weren’t first-timers. Hasan Rizvi had scaled major technology groups at Oracle. Rahim Yaseen had crisscrossed the enterprise stack from Siebel to Couchbase. Michael Fortson-Dillon, Qlue’s Director of Mobile, would go on to lead major product efforts at ServiceNow post-acquisition. Amit Jusuja, who helped operationalize Qlue, had shaped Java and IoT platforms. And Ken Laversin, Qlue’s sales advisor, later led GTM at AI unicorns like C3.ai and Skyflow.

This wasn’t a random crew; it was a dream team of seasoned enterprise technologists who saw the future before it arrived.

The Acquisition That Planted Seeds

ServiceNow wasn’t looking for flash. It was looking for fit.

Qlue’s tech would become the bedrock for ServiceNow’s Virtual Agent, integrated into IT, HR, Customer Service, and more. What started as a way to answer common questions turned into a multi-billion-dollar category of AI-driven workflows, accelerated by real conversations between humans and machines.

Even more importantly, the Qlue acquisition represented a strategic thesis that’s shaped every AI initiative since: automation is only powerful when it feels human.

This wasn’t just about reducing ticket volumes. It was about reimagining what it felt like to get help at work.

Lessons for Builders

Reflecting on Qlue today, several lessons emerge, especially for those of us building the next generation of tools in AI, enterprise, and beyond:

• Start with the pain, not the tech. Qlue wasn’t chasing a chatbot trend. It was solving a clear, high-friction pain: enterprise interactions were slow and impersonal. It didn’t build for buzzwords, it built for needs.

• Bet on small, sharp teams. For all the headlines about mega-acquisitions, it’s often the nimble, focused teams that reshape platforms. Qlue had the right mix of experience and humility to plug into a larger vision.

• Human-centered AI wins. Qlue succeeded not because it was the smartest AI, but because it was the most empathetic. It understood that in the enterprise, clarity and speed are forms of respect.

• The right acquirer matters. ServiceNow didn’t just buy Qlue and bury it. It amplified it. It gave Qlue’s ideas a canvas, one that reached tens of millions of users.

Final Thought

Every builder dreams of creating something lasting. Qlue didn’t become a household name, but it did become a foundational layer in a platform that millions now depend on to get work done faster.

And that’s a kind of legacy worth chasing, not for the headlines, but for the users quietly saying thank you every time the chatbot just works.

So here’s to the quiet revolutions, the little startups with big hearts, and to the builders bold enough to see the future not as a pitch deck, but as a conversation worth having.

This is part of a series I’m writing to inspire myself and other builders by shining a light on companies that ServiceNow has acquired. If you’re dreaming of building something yourself, these stories aren’t just history, they’re playbooks with lessons we can learn.

A Glimpse into DxContinuum

Founded in the heart of Silicon Valley, DxContinuum set out to make machine learning practical for enterprise teams long before "AI" became table stakes. Their flagship product, Fathom, used predictive modeling to classify and route business requests, transforming what was once a noisy, manual workflow into a smarter, faster, data-driven engine.

Their focus wasn’t on generic AI, it was purpose-built for line-of-business outcomes, like improving sales pipelines and automating IT and HR workflows. And it didn’t just work in a lab; it proved its value on platforms like Salesforce.

When ServiceNow acquired DxContinuum in January 2017, it wasn’t just a tech pickup, it was a signal. A signal that intelligent automation was no longer a nice-to-have, but the next chapter of enterprise workflow.

Meet the Founders

At the core of DxContinuum’s success was a founding team with deep roots in data, enterprise platforms, and predictive modeling.

• Debu Chatterjee, the founder and CEO, brought decades of experience from Oracle, Informatica, and FICO. His passion for structured data and predictive outcomes culminated in the patented Fathom engine and eventually shaped ServiceNow’s AI roadmap as its founding Head of AI.

• Baskar Jayaraman, CTO and co-founder, merged hard science with practical application, developing early AI systems for health insurance at FICO and sales optimization tools for TrueDemand. At ServiceNow, he continued to lead in the AI/ML space before founding his next venture, Konfer.

• Kannan Govindarajan, VP of Product, had a long track record at Oracle and HP, where he led architecture and strategy. At DxContinuum, he helped refine the product vision and, later at ServiceNow, scaled that vision across multiple AI initiatives.

This wasn’t a hype team. It was a high signal, low noise group of builders, working at the intersection of AI and enterprise utility.

What the Product Did

DxContinuum’s core offering, Fathom, used machine learning to anticipate outcomes. It could predict which sales leads would convert, route service requests with precision, and assign IT tickets to the right teams—automatically.

What made it special was its instance-specific modeling. Instead of building a single model across multiple companies (like many SaaS AI solutions at the time), Fathom trained custom models on each customer’s data. That meant better accuracy, less noise, and models that could learn your business, not someone else's.

The goal was always the same: put intelligence into the workflow without asking users to change behavior. In a way, it made the enterprise feel more like consumer tech—smart, invisible, and always learning.

The Acquisition

On January 18, 2017, ServiceNow announced it was acquiring DxContinuum in an all-cash deal. The plan was clear: embed Fathom’s predictive models into the Now Platform to supercharge intelligent routing, categorization, and decision-making across IT, HR, CSM, and beyond.

This wasn’t just about AI for AI’s sake, it was about making workflows frictionless. The acquisition directly supported ServiceNow’s vision of moving work from people to machines, allowing employees to focus on high-value tasks while the platform handled the rest.

It also marked a shift toward platform-native intelligence. Rather than bolting on AI, ServiceNow was baking it in, starting with the DNA from DxContinuum.

Where It Stands Today

DxContinuum’s legacy lives on in what became Predictive Intelligence within the ServiceNow ecosystem. By 2018, features like ticket categorization, assignment suggestions, and risk scoring were quietly transforming workflows behind the scenes.

Today, Predictive Intelligence powers AI-driven suggestions across modules. The same philosophy—instance-specific models trained on customer data, still guides how ServiceNow delivers machine learning features.

And many of the original DxContinuum team stayed on to scale those ideas further before moving on to build again. Their fingerprints are still visible across ServiceNow’s AI stack, and even in the startup ecosystem through companies like Konfer and ThetaRho.

What I’m Taking From This

1. Solve real workflow pain, not just cool tech.
DxContinuum didn’t pitch “AI.” They solved routing, triage, and pipeline prediction. Every use case was grounded in how work actually happens.

2. Bake intelligence into the process.
The genius of their product was invisibility. Users didn’t need to think about the model, it just worked. That's the kind of UX that wins in the enterprise.

3. Don’t chase general models—build for the instance.
DxContinuum’s insistence on customer-specific models made their predictions more accurate, more useful, and more trustworthy. It’s a model worth stealing.

Sources

Mike Kaufman - https://www.servicenowelite.com/blog/2017/1/19/servicenow-acquires-dxcontinuum

Press Release - https://www.servicenow.com/company/media/press-room/servicenow-acquires-dxcontinuum.html

This is part of a series I'm writing to help remind myself (and anyone else building) that it's possible. These aren't just stories about companies ServiceNow bought. They're reminders that someone out there built something worth acquiring.

The Origin of BrightPoint Security

BrightPoint Security started out in the early 2010s under the name Vorstack. Back then, enterprise security teams were buried in threat data, and “sharing” usually meant either oversharing or not sharing at all. BrightPoint showed up with a smarter idea: help organizations securely share and act on threat intel, without giving up control.

By 2016, they had sharpened their message and positioned themselves as a real player in threat intelligence:

That’s not just filtering spammy alerts, that’s reducing months of work into minutes.

The Team Behind the Vision

These folks weren’t just punching above their weight—they knew what they were doing:

Andreas Haugsnes – Co-founder and technical lead. Started in engineering, worked in security at Zynga and LiveOps, and kept going post-BrightPoint at Unity. The guy knows his way around real-time threat systems.

Joe Eandi – Co-founder, initial CEO. Law background. Worked in early exec roles at Mojam and Inktomi. He helped get BrightPoint off the ground and into acquisition territory. Went on to co-found Cyber Mentor Fund.

Ravi Iyer – SVP of Products. Led product across big names like Sun, Nokia, and Good Tech. Post-BrightPoint, he landed exec roles at Splunk, Ivanti, Cybereason, and Veracode.

Scott Lewis – VP of Product. Assisted in the development of the product roadmap, joined ServiceNow after the acquisition and was responsible for the re-platforming into ServiceNow.

Rich Reybok – CTO at the time of the acquisition. Came from Redzone Security, Merrill Lynch, and Asurion. He joined ServiceNow after the acquisition and now runs software engineering there.

Anne Bonaparte – Took over as CEO during BrightPoint’s growth stage. Had already been CEO of a few successful exits: MailFrontier, Tablus, Solidcore, Xora. She's a go-to operator for getting companies across the finish line. I was so amazed by Anne’s history I spent all week thinking about it.

3. What BrightPoint Built

Their product was called Sentinel. It let organizations automate how they shared and correlated threat intel, internally and externally. It wasn’t just pulling in feeds and calling it a day. It was about real-time collaboration with trust boundaries in place.

This meant faster detection, stronger signals, and fewer blind spots. It gave teams the ability to share what mattered and act on it with context.

It looked more like a trust network than a feed parser. That was the difference.

The Acquisition by ServiceNow

ServiceNow picked up BrightPoint in an all-cash deal around May 2016. The price wasn’t disclosed, but it came just a month after they acquired ITapp. This was during a time when ServiceNow was just getting serious about security operations.

The deal gave ServiceNow instant credibility in threat intel automation. BrightPoint’s tooling slotted in to help accelerate the Security Operations suite, especially around detection and response.

They also had connections with RSA and IBM, and had raised around $8.4M. That kind of backing made it clear this wasn’t a fluke.

Where It Stands Today

You won’t find the BrightPoint name anywhere now, but its DNA is all over ServiceNow’s security products. The core tech lives on in Security Incident Response and Threat Intelligence.

These apps help teams triage faster, connect data points, and automate what used to take hours or days. BrightPoint brought the “intel” into what used to be just a ticketing workflow.

Lessons & Takeaways

Noise Reduction = Value
BrightPoint didn’t invent threat intel. They just made it actually useful. They cut through the noise, and that made all the difference.

Security Doesn’t Have to Be a Solo Sport
They built tools for collaboration. Shared defense. That was rare at the time, and it stood out.

An Exit Isn’t the End
Getting acquired wasn’t the finish line. It gave BrightPoint’s team a bigger platform, and gave ServiceNow a boost into a new product area.

Sources:

• brightpointsecurity.com (archived)

• ServiceNow acquisition announcement (via Fortune)

This is part of a series I’m writing to inspire myself and other builders by shining a light on companies that ServiceNow has acquired. If you’re dreaming of building something yourself, these stories aren’t just history, they’re playbooks with lessons we can learn.

What Was ITapp?

Founded in 2012 and based in San Jose, ITapp set out to make managing cloud infrastructure easier for businesses. They did this with visual app assembly, faster intergrations, and a streamlined, cost-effective approach to cloud orchestration.

Back then, I wasn’t building full-stack sites yet and didn’t realize the significance. In hindsight, it’s clear this was a big deal. ITapp wasn’t just offering cloud management, they made it easy. Look at Netlify and Vercel: both wrap complex infrastructure from AWS or Google Cloud in an easy-to-use package. ITapp was doing something similar.

On their website in 2015, ITapp made some big claims:

• 75% faster installation in HA mode

• 80% faster integration time

• 75% less complexity in app assembly

• 40% lower cost than competitors

It wasn’t just hype. The integrated with AWS, Azure, OpenStack, Citrix XenServer, and VMware. They weren’t trying to reinvent the wheel; they wanted to make it easier to drive.

The Founders: Seasoned Builders, Not First-Timers

ITapp’s founding team was stacked with enterprise veterans:

• Brajesh “BG” Goyal brought deep technical and product experience from Oracle and NetApp, and would go on to lead product integration of ITapp at ServiceNow after the acquisition.

• Brian Krug, previously a VP at Cisco, co-founded ITapp and later served as VP of Product Success at ServiceNow before founding AppFaktors.

• Giridhar “Gigi” Padmanabh came with cloud experience from newScale (acquired by Cisco) and became a Senior Director at ServiceNow.

• Andrew Tahvildary, though not a founder, was an early advisor and investor. Bringing in battle-tested engineering leadership from his time at Primavera, newScale, and later companies acquired by Oracle, EMC, and Apple.

This wasn’t a bunch of first-time founders learning as they went. These were people who had built and shipped real enterprise software at scale, and were now playing to win.

The Product: A Next-Gen Cloud Management Platform

ITapp positioned itself as a next-gen cloud management platform with a visual, policy-driven approach to provisioning and orchestration. You could:

• Visually assemble full-stack applications

• Attach custom storage and networking containers

• Manage quotas and delivery across multiple cloud providers

• Automate deployments with integrated CI/CD pipelines

It was part cloud broker, part orchestrator, part DevOps enabler, built with the enterprise in mind.

4. The Acquisition: ServiceNow Buys In

In April 2016, ServiceNow acquired ITapp for $15 million.

It was a quiet but strategic move. At the time, ServiceNow was aggressively expanding beyond its help desk roots into broader IT Operations Management (ITOM) and cloud-native tools. ITapp wasn’t about giving ServiceNow new capabilities from scratch, it was about accelerating their existing cloud management roadmap.

As Sri Chandrashekar, then VP/GM of ITOM at ServiceNow, put it:

The goal: take ITapp’s tech and integrate it deeply into the Now Platform, giving ServiceNow-native experiences for cloud provisioning, governance, and policy enforcement.

Where It Is Today: From ITapp to Cloud Management to Cloud Accelerate

ITapp’s DNA lives on in ServiceNow Cloud Management, officially launched in May 2017. Over time, the product has evolved, been repackaged, and now sits under Cloud Accelerate as part of the AI Ops Enterprise offering.

What started as a standalone cloud orchestration platform has become a foundational element in how ServiceNow helps enterprises manage cloud at scale—wrapping it in workflows, automation, and policy enforcement powered by the Now Platform.

What We Can Learn

Here are three takeaways for builders and product-minded folks:

1. Solve real problems, not just trendy ones.
ITapp didn’t try to ride the latest hype wave. They focused on pain points, complexity, cost, integration time, and built something that made a difference.

2. Deep enterprise experience matters.
The founding team knew their buyers, their constraints, and how enterprise IT works. That domain knowledge gave them credibility and clarity.

3. Integration can be more valuable than innovation.
ServiceNow didn’t need a shiny new product. They needed a way to deliver cloud management faster. ITapp gave them a shortcut.

Back in 2012, I spent many evenings and weekends on the ServiceNow Community, answering forum posts, helping people troubleshoot tricky platform issues, and doing whatever I could to level up. (Shoutout to October 2013 - Member of the Month was a proud moment!)

While I was busy solving problems post by post, something bigger was brewing behind the scenes: a small group of consultants saw an opportunity to transform how organizations approached governance, risk, and compliance. That group became Intreis - and their work helped shape ServiceNow's entire GRC offering.

This is part of a series I’m writing to inspire myself and other builders by shining a light on companies that ServiceNow has acquired. If you’re dreaming of building something yourself, these stories aren’t just history, they’re playbooks with lessons we can learn.

Though my personal memory of Intreis is limited, I’ve learned that they ran a highly focused consultancy around Governance, Risk, and Compliance. ServiceNow noticed and wanted them to help.

Kristopher Markham and Morgan Hunter

Every great company starts with a couple of people who see things differently. In the case of Intreis this was Kristopher Markham and Morgan Hunter.

Kristopher had deep technical knowledge of ServiceNow, and Morgan brought real world experience from her time at Kantar IT Partnership.

In hindsight, a clear opportunity had presented itself: to bring governance, risk, and compliance practices into the same workflow-driven systems that were already transforming IT operations. Intreis (wayback link) was formed in 2012 to explore that opportunity, and in just a few years, they would help define the foundation for what became ServiceNow’s GRC product.

What did Intreis do?

Rather than treating compliance as a siloed function that was just a box to check, Intreis embedded it directly into ServiceNow’s ITSM workflows, allowing businesses to streamline both operations and compliance. The idea was to leverage existing platforms, like ServiceNow, to build frameworks that didn’t just help businesses meet compliance requirements, they helped them operate more efficiently, too.

The Acquistion

In 2015, after a few years of refining their approach and proving its value, ServiceNow recognized the opportunity to deepen their GRC offering and acquired Intreis. This acquisition wasn’t just about adding another tool to the GRC stack. It was about deepening the GRC capabilities of ServiceNow’s platform. Kristopher and Morgan, having already worked closely with ServiceNow, helped shape this offering, bringing practical, real-world experience to the table. Once there Kristopher worked on expanding the GRC product, and Morgan helped partners and ServiceNow strategy around said partners.

The Legacy

GRC is still a large part of the platform and companies solely focus on it today. This product wouldn’t be where it was without this acquisition. If you’re using the Unified Compliance Framework you’ve benefited from this acquisition.

What I’m taking from This

Make compliance work for the business - Intreis didn’t build a tool. They solved a real problem by embedding compliance into existing workflows. This was essential to operational effectiveness.

The power of deep, hands-on experience - Kristopher and Morgan’s time at Fruition Partners and Kantar IT gave them a wealth of knowledge about the challenges businesses face when integrating compliance. This insight was essential in shaping how GRC could be delivered more effectively within ServiceNow.

Entrepreneurship never stops - Even after their time with ServiceNow, Kristopher and Morgan continued to innovate by founding new ventures (Serentiy EHS, and Medusaas). Their journey is a reminder that the spirit of entrepreneurship is about continual growth and the pursuit of new opportunities.

Virtual Private Servers.... There's a little bit to know here. I was trying to find a good comparison site. Didn't see one so thought I'd toss my notes up here. These prices were as of December, 2024.

1. Not all hosts are the same.

2. Shared vCPU = Allowing multiple customers to compete for the same vCPU

3. Dedicated vCPU = No one else can have it

4. vCPU = # processors ✖️ ( # cores ✖️ # of threads ). E.g. my home computer has 1 processor with 8 cores, and 8 threads. = 64vCPU

Let's start making some notes....

🧩 Best Value Shared Hosting (1 vCPU / 1GB RAM)

🧩 Best Value Shared Hosting (4 vCPU / 8GB RAM)

🖥️ Best Value Dedicated Hosting (4 vCPU / 8GB RAM)

🏗️ Best Value Bare Metal

🎮 Best Value GPU Hosting

The Story of Neebula: From Startup to Strategic Acquisition

This week, I’ve been looking into the story of Neebula Systems, a company founded by Yuval Cohen, Ariel Gordon, and Shai Mohaban. Their central idea was simple but powerful: what if infrastructure wasn’t viewed in terms of servers and applications, but rather by the business services those systems actually deliver?

They called their product ServiceWatch, and it offered a top-down perspective of an organization’s environment. Rather than managing raw infrastructure, ServiceWatch created dynamic service maps, automatically updated as configurations changed. This gave IT teams a clear view of how different components supported business services and allowed them to understand the real impact when something went wrong.

Neebula didn’t raise an enormous amount of money, just $5 million. That’s still a significant sum, but in startup terms, especially for a team that grew to 35 people, it wasn’t extravagant. What they did raise, they used wisely. They built a focused, high-value product in a short amount of time and proved its worth quickly.

ServiceNow took notice. Just four years after Neebula was founded, ServiceNow acquired the company for $100 million, an impressive 20x return on the initial investment. After the acquisition, the founders went on to work at ServiceNow, with Yuval Cohen eventually serving as VP and CISO. They later moved on to explore other opportunities as angel investors and advisors.

If you’ve worked with ServiceNow, you might recognize the legacy of ServiceWatch. It became the foundation of ServiceNow’s Service Mapping capability. What ServiceWatch introduced was a shift from managing infrastructure to managing services, a forward-thinking model that’s now central to modern IT operations.

Some tools fade after acquisition. Others become part of the foundation.
The difference? Execution, timing, and a willingness to keep going.

Stuff I’m Taking From This

1. Be early, but useful
   Neebula wasn’t just ahead of its time with service modeling—they made it deployable. That combo matters. Vision without usability is just a pitch.

2. Your users are your leverage
   They didn’t wait for a market to form. They helped shape one by solving a real ops pain. That clarity attracts the right early adopters.

3. M&A isn't the end—it's a fork
   The Neebula team could’ve bounced after the sale. Instead, they helped re-architect what became the CMDB for one of the biggest IT platforms in the world. That’s impact.

If you're building something in that same spirit. Early, useful, and bold. I’d love to swap notes.
https://meetings.hubspot.com/jace-benson

The Midnight Distraction

It’s 1:33 AM. I should be fixing a bug, but here I am writing this post again.

I got sidetracked reading an old ServiceNow press release from 2013.
"ServiceNow acquires Mirror42 to power Performance Analytics."
I remember Mirror42, kind of. But I never really knew the story behind it.

Turns out, it wasn’t just some BI tool that got scooped up and forgotten.
Karel van der Poel built it from scratch, sold it, and stuck around. And then made it even bigger. Also, he has a YouTube video about this he made 12 years ago (5 minutes).

That hit me.

Phase 1: Just Survive (2004–2008)

Back then, Mirror42 was an on-prem BI tool. No funding. No fluff. Just solving a problem for real customers.
By 2008, they were profitable.

Karel wasn’t trying to go viral. He was trying to stay alive.
And that worked.

Phase 2: Betting on the Cloud (2008–2010)

In 2010, the cloud was still weird to a lot of people. Karel rewrote the whole stack to support it anyway.
He didn’t chase the trend. He saw what was coming.

Phase 3: Building with Community (2008–2013)

While scaling the company, Karel launched something wild.
KPI Library.
A shared space where 400,000 people added 6,000+ metric templates.

He basically open-sourced strategy. That move built trust, reach, and a moat.

After the Acquisition

ServiceNow bought Mirror42 for $13M.

Most people would walk away.

Karel didn’t.
He scaled Performance Analytics to $75M+, then helped launch NowX and over 30 new products inside ServiceNow. This is generally part of premium SKUs, or a standalone product at a double-digit percent annual contract value increase.

He didn’t stop at the finish line. He treated it like the start of the next thing.

Stuff I’m Taking From This

1. Build for deployment, not hype
Karel made something useful for real teams. He focused on being installable, usable, and flexible.

2. Community matters
KPI Library wasn’t flashy, but it created something that lived on.
Letting users shape the product made it stronger.

3. Long games win
Nine years at Mirror42. Eleven years (and counting) at ServiceNow.
That’s what sticking with it looks like.

Not everything needs to go big right away.
Sometimes you just need to make something that works, solve a problem, and keep showing up.

That's what Karel did.
That’s what I want to do too. If you want to know about that, schedule a meeting with me on https://getaiinabox.com 

Want to see more, here’s some interesting links.

Table of Contents

• 1. Getting Started

  • 1.1. Installing Ruby on Rails

  • 1.2 Setting up your Rails app

  • 1.3. Creating a home page

  • 1.4. Cleaning up the application styles

  • 1.5. Replacing the Home page content

  • 1.6. Setting up User Login with Devise

  • 1.7. Making the Navbar stick to the top

  • 1.8. Adding a dashboard after login

  • 1.9. Hiding Login and Register for logged in users

• 2. Deploying

  • 2.1. Getting the things ready

  • deploy.yml - setting the things up

  • Installing Kamal

  • Configuring the deploy.yml

    • service

    • image

    • servers

    • proxy

    • registry

    • env

  • Setting up .env

  • Running kamal setup

  • Setting up a path for sqlite

  • Testing over http on the ip address

  • Adding a domain and SSL

• Useful resources

Okay, so I’m learning Ruby on Rails. I’m looking forward to working on something that doesn’t constantly shift and has been out there for quite a while. I also love the idea of all the generators.

That being said, if you’re working on rails app and you deploy there’s always a number of steps here. I’m going to try to spell out everything I did from the getting started page on ruby on rails to the kamal deploy comand.

Let’s get into it.

1. Getting Started

I started the Getting Started tutorial this week. I however hit some snags. So we’re going to skip it and follow what Indigo Tech Tutorials published. There’s a few prerequisites we got to meet first.

1.1. Installing Ruby on Rails

They have a page here, for my set up (building on Windows) Here’s my notes.

1. Install WSL for Ubuntu

   wsl --install --distribution Ubuntu-24.04

2. Open it up, create a user, and password you will remember.

3. Install a few things

# install the packages needed
sudo apt install build-essential rustc libssl-dev
sudo apt install libyaml-dev zlib1g-dev libgmp-dev

# get mise to install ruby on rails 3
curl https://mise.run | sh
echo 'eval "$(~/.local/bin/mise activate bash)"' >> ~/.bashrc
source ~/.bashrc

# install ruby
mise use -g ruby@3

# verify ruby
ruby --version

# install rails
gem install rails

# verify rails
rails --version

1.2 Setting up your Rails app

You should be on your terminal in WSL.

Let’s make a new project we’ll call it rubystore with Tailwind.

rails new rubystore -c tailwind
# this will build the project out
cd rubystore
code . #open in vs code

I press the ctrl+` to open the terminal in the editor.

1.3. Creating a home page

Now let’s set up the controller

rails g controller pages home

You’ll want to edit the config/routes.rb file to match this.

Rails.application.routes.draw do
  # Define your application routes per the DSL in https://guides.rubyonrails.org/routing.html

  # Reveal health status on /up that returns 200 if the app boots with no exceptions, otherwise 500.
  # Can be used by load balancers and uptime monitors to verify that the app is live.
  get "up" => "rails/health#show", as: :rails_health_check

  # Render dynamic PWA files from app/views/pwa/* (remember to link manifest in application.html.erb)
  # get "manifest" => "rails/pwa#manifest", as: :pwa_manifest
  # get "service-worker" => "rails/pwa#service_worker", as: :pwa_service_worker

  # Defines the root path route ("/")
  root "pages#home"
end

At anytime you can test this by running bin/dev. Let’s do that and ensure you get the page was generated page.

1.4. Cleaning up the application styles

Open the /views/layouts/application.html.erb and let’s remove the classes on the <main> element.

1.5. Replacing the Home page content

Open the /views/pages/home.html.erb, and look for a landing page template with tailwind, searching for free tailwind css components will find you some sites. I found this one called Landing Page by zoltanszogyenyi.

Copy the code and past it in that file. Run you server and check it out.

1.6. Setting up User Login with Devise

On the terminal add the devise and tailwind devise gems, and the user model and migrate that to the database.

bundle add devise tailwind_devise
rails g devise:install
rails g tailwind_devise:views
rails g devise User
rails db:migrate

Open the /views/pages/home.html.erb and find the register and login links.

Update them with the following.

Login link should use the following hrefs 

<a href="<%= new_user_registration_path %>">Register</a>
<a href="<%= new_user_session_path %>">Login</a>

1.7. Making the Navbar stick to the top

First let’s edit the /views/layouts/application.html.erb by adding this in in the body tag.

<%= render "layouts/navbar" %>

Find the header html content and cut it from the /views/pages/home.html.erb, and paste it into a new partial file /views/layouts/_navbar.html.erb 

You can test this out by registering. You won’t notice anything different after logging in. Let’s fix that.

1.8. Adding a dashboard after login

We’re going to create a new controller definition in /controllers/pages_controller.rb It should look like this.

class PagesController < ApplicationController
  def home
  end

  def dashboard
  end
end

We need to now tell the routes to handle authenticated users by adding this authenticated logic.

Rails.application.routes.draw do
  devise_for :users
  get "pages/home"
  # Define your application routes per the DSL in https://guides.rubyonrails.org/routing.html

  # Reveal health status on /up that returns 200 if the app boots with no exceptions, otherwise 500.
  # Can be used by load balancers and uptime monitors to verify that the app is live.
  get "up" => "rails/health#show", as: :rails_health_check

  authenticated :user do
    root "pages#dashboard", as: :authenticated_user_root
  end

  # Defines the root path route ("/")
  root "pages#home"
end

Lastly, before you can test this, you’ll need a dashboard page. Create one at /views/pages/dashboard.html.erb. Like before find a tailwind component that makes sense. I’m using Dark Dashboard Example by pantazisoftware.

Okay now the login and register loads and lands on the dashboard.

1.9. Hiding Login and Register for logged in users

Edit the /views/layouts/_navbar.html.erb partial.

We’re going to wrap those links we modified above with this snippet.

<% if current_user %>
    <a
        href="<%= destroy_user_session_path %>" 
        data-turbo-method="delete"
        class="...">
        Log out
    </a>
<% else %>
    <!--your links here-->
<% end %

Now that it’s all set up. Try it out and when you're ready let’s deploy it.

2. Deploying

2.1. Getting the things ready

You’ll need a few things to get started here.

1. A docker registry (I’m using hub.docker.com) with an access token

2. A SSH Key

3. A server (I’m using Hetzner) with a SSH Key

4. A folder on the server where we’ll store our sqlite and other storage stuff.

5. dovenvx to allow us to set up the secrets and environment variables easily.

deploy.yml - setting the things up

There’s a lot in this file, I’m just going to paste my uncommented version, you can read more on it on the official Kamal Configuration page.

Installing Kamal

On the terminal install kamal, then initialize it for the current project.

gem install kamal
kamal init # this may throw a message that Config already exists
# that's okay.

Configuring the deploy.yml

I want to lay out all the things you’ll need for this, but there’s a bunch. Instead I’m going to address each configuration.

service

The service is the name of your application. I’m going to just call mine rubystore

image

This is the docker image. You’ll need a docker registry to do this. I’m using dockerhub. You’ll need to create an access token on docker hub. Make sure it has read and write permissions. You can use another registry, I’m not going to set that up. This value should be you’re username/repo. Put this in the .env file (create it if it doesn’t exist). You should have something like this

KAMAL_REGISTRY_PASSWORD=your_key_goeshere12345

servers

Here we need the IP address of the server we’re going to deploy to. Spin up a machine on Hetzner that is running Ubuntu and at least 1 GB of ram. Copy that IP address here.

proxy

Initially we’re going to skip this so comment this block out. You can do that by prepending a # for each line here.

registry

Kamal uses docker hub by default, we are also going to use that. Set the username here. This block lets you connect to different registries.

env

The env block defines what environment variable get passed as secret or as clear text. Here we’re just going to pass the secret of RAILS_MASTER_KEY. To send that the secrets for Ruby is odd to me yet. You’ll need edit the ./kamal/secret and add RAILS_MASTER_KEY=$RAILS_MASTER_KEY. I’ll write a little more about this for the kamal commands later.

Setting up .env

Now Kamal needs access to the KAMAL_REGISTRY_PASSWORD and RAILS_MASTER_KEY. Create a .env file and put those in there. Getting your master key is as easy as opening ./config/master.key. If you don’t have a file there run rails credientals:edit and then just exit using :q. Now you will have that master.key file.

KAMAL_REGISTRY_PASSWORD=dckr_pat_asdf
RAILS_MASTER_KEY=asdfasdfasdf

Running kamal setup

Running kamal setup needs some details available to it. To set these we’ll just prepend the command with these environment variables. Kamal also needs to be on a machine that can connect to the server. That means setting up ssh on that server and this one, or typing in the ssh password.

A note, on windows you need to have docker desktop installed and integrated with the ubuntu wsl you are running. Microsoft WSL Docker page has some instructions on this.

kamal setup

Sometimes I get an error running this

  INFO [fd944dda] Running docker login -u [REDACTED] -p [REDACTED] as jace@localhost
  ERROR (SSHKit::Command::Failed): docker exit status: 32000

If you get this, your .env or .kamal/secrets file probably isn’t working properly. I found that I can run kamal secrets print to see what secrets are available to kamal. This is great for debugging.

I ended up install dotenvx to correct this.

curl -sfS https://dotenvx.sh | sudo sh

Then updated the secrets file to have this for the KAMAL_REGISTRY_PASSWORD.

KAMAL_REGISTRY_PASSWORD=$(dotenvx get KAMAL_REGISTRY_PASSWORD --quiet -f .env)

This just worked for me! Sweet. However, when I try to register, I don’t get logged in.

Setting up a path for sqlite

Erik Minkel wrote a piece on how he set’s this up so the sqlite file doesn’t get destroyed on every deploy.

We’re going to copy his lead.

To that we need to ssh on the machine and create directories for the database and for storage. We’ll give proper permissions to those folders. We’ll add the volumes into our deploy.yml file.

We’ll need to ssh onto the server to create the folders

ssh root@yourserversipaddress
sudo mkdir /db
sudo mkdir /storage
sudo chown 1000:1000 /db /storage

Log off the server and edit the deploy.yml locally by adding

volumes:
  - "/db:/rails/sqlite"
  - "/storage:/rails/storage"

Now let’s add these changes to git, and redeploy.

git add .
git commit -m "added volumes"
kamal deploy

Testing over http on the ip address

Okay this is not where we want to leave things but I like to test things out.

To test out the site it should be up right now but if you try to auth, you’ll have issues. That’s because when signing up you get the following error on the console (visible by kamal logs )

If you search for Processing by Devise::RegistrationsController#create you’ll find ActionController::InvalidAuthenticityToken (HTTP Origin header (http://1.2.3.4) didn't match request.base_url (https://1.2.3.4))

Okay, let get around that. In the /config/environments/production.rb there’s an config.force_ssh which were going to change to false and a config.assume_ssl which we’ll comment out.

Do another deploy, and success I’m able to register an account and log in on separate windows.

Adding a domain and SSL

First part of this is configuring your Domain Name Server to point to your server.

Then undo what we did before.

1. Open /config/environments/production.rb

2. Update config.force_ssl to true

3. Uncomment config.assume_ssl 

kamal proxy logs
kamal proxy reboot 

Useful resources

I found “How To Deploy Rails 7 App With Kamal 2” by Indigo Tech Tutorials the most useful. He’s able to offer help too for a fee on his site, Indigo Tech Tutorials.

Kamal Deployment: The Newest Form of Self-Torture | I'm Mary Poppins, y'all!

How to configure Kamal and avoid common deployment pitfalls

alec-c4.com/posts/2025-04-02-kamal

The db_image, db_video, and db_audio tables in ServiceNow do something interesting: they completely ignore access controls (ACLs). That means any file stored here is publicly accessible. While this is great for assets like images in public-facing knowledge base (KB) articles, it does come with some caveats.

For example, files from these tables are served straight from the root domain (e.g., https://support.service-now.com/image.png). This makes them easy to link to, but it also bypasses user permissions entirely. In some cases, this behavior can cause issues. I’ve seen KB articles with copied images that still point to the original article, which some users couldn’t access. The attachments copy forward with the article, but the image references in the HTML don’t update.

I got curious and tested a few edge cases, like uploading files without extensions or trying to host unauthorized content. ServiceNow held up. Files without extensions still work as expected, and there doesn’t seem to be a way to abuse this feature for anything malicious. That said, the lack of ACL checks is still something to keep in mind.

This isn’t necessarily a problem, but it’s worth noting. If you’re using these tables, make sure they’re only for files you intend to be public. Also, if you’re working with KB articles, double-check your image references when creating new versions. A little awareness here can go a long way toward keeping things working smoothly.

I'm building a solution and as part of this, I'm trying to make a easy to show interactive environment.

One of the things I was thinking about was setting up Delegated development on my Personal Developer Instance.

It became apparent to me that I didn't understand Application Administration compared to Delegated Development, at least not how the docs say.

If you're coming across this and want to know the difference, here it is.

1. Application Administration is the functionality to restrict standard administrators from accessing a scoped application. Think Human Resources Service Delivery. You may not want global admin's mucking up columns on their tables, business rules, flows, etc.

2. Delegated Development is the functionality to invite and allow others to build automation within a specific scope.

I want to take a few moment and dive into each a little more as my understanding now, may help me later when.

Application Administration

This was not what I was looking for before, but let's talk about it, and how you can set it up.

You need a scoped application to get this, and then once you look at the scoped application you'll notice a checkbox next to Application Administration that looks like it's a simple check. It is, but you wont be able to save that record until you have a role with the Application Administrator of true.

Here's a quick and dirty checklist to try it out.

1. Create a scoped application

2. Change your current scope to the new scope.

3. Create a role.

4. On the list view of the role, show Application Administrator

5. Set Application Administrator to true

6. Go back to "My company applications" and click the left-side of the tile to open the application's details.

7. Check the box.

What did this just do? Well, if you don't have this role, you wont be able to mess with anything inside of that scope.

Delegated Development

This was what I was looking for, but after seeing it, I'm not user it's what I need.

Let's say you wanted to let some folks not on your team build on ServiceNow in a way that is separated by scope from you. This would be how to achieve that. Here's a quick list of steps to try it out.

1. Create a scoped application

2. In the related links you might see "Manage Collaborators" from the App, or in Legacy studio under the file menu, you can see the same.

3. Click on that, a Modal will appear with a invite field, and level.

   1. So it appears you can pick anyone

   2. The level's are limited to editor and owner. Owner should include all access, and it nearly does. It's missing the scripting option.

   3. Pick a user, or better create a user with no roles, then pick that person.

   4. Pick owner

4. Once that's submitted, you'll probably notice something about the request being auto rejected. This is... by design. I forgot to mention you will need to ensure the group, App Engine Admins need's to have some folks in it who can approve these tasks.

5. Start over, at step 3. Welcome back.

6. Now you might be wondering what task did this create? It made a sn_collab_request_dev_collab_task record and an approval against it to the group App Engine Admins.

7. You can look up the flow, it has over 30 steps. If you approve the request the user will be given over 20 roles (given you gave them "owner" access).

8. Now if you have them or impersonate them to see what they can do, you can notice you can see all the appropriate buttons in legacy studio and the new ServiceNow studio to create flows, business rules, portal widget etc. However, you may notice, they can't edit or create any scripts in those records.

9. Stop impersonating them and go back to where you invited them, that modal. You'll see they are listed as a collaborator, go ahead and change their access.

10. See the options, there's a "Allow Scripting" near the bottom.

Further Reading and thoughts

These two features might be a bit weird to understand. Hopefully this helped. Thanks John Dahl for letting me bounce these ideas around with you, that helped me get to this understanding faster.

If you'd like to read more on this, these are the links I was using to try to understand it.

• Docs: Delegated development and deployment

• Docs: Application administration

• Dan Covic: Citizen Development

• Lisa Holenstein, Kiernan McMorrow, and Robert Ninness Platform Academy Video (43 mins)

The Message of the day on linux is helpful, but its long and... a little hard for things to stand out.

I had a few questions about the MOTD.

1. Where is it stored?

2. How is it set up?

3. Can I change it?

4. If I can, how can I test it?

Where is the MOTD stored?

The message of the day on Ubuntu is stored in the /etc/update-motd.d/ folder as a number of scripts.

You can view these scripts by running ls -la /etc/update-motd.d/

How is the MOTD set up?

The Message of the day is broken up into individual scripts. Here's what mine currently shows.

It seems that cat /run/motd.dynamic is run when you login and something else generates it. At least according to, chriserin on their blog.

Can you change the MOTD?

Yes. There's loads of ways to do this.

I don't want to remove it for everyone so you can disable it on a user by user basis by doing this;

touch $HOME/.hushlogin

Then you can add a custom script or echo to /etc/profile/ and it will print it at the end.

I added `neofetch` to mine.

Further Reading

server - How is /etc/motd updated? - Ask Ubuntu Working with the Ubuntu Message of the Day (MOTD) Service | Vultr Docs

Sometimes you need new code converted to things ServiceNow understands. Arrow functions now work in ServiceNow in some places but not others. let, const same thing.

Here's a way to take any new script and make it work. This is called transpiling. It's complicated. The way I understand it is, you give it new code, and it makes it work with and older set of JavaScript features that were available a long time ago using polyfills.

Enough dry stuff let's get trying it.

Go to babeljs.io/repl and set the target to, defaults, ie 11.

Then paste in the new JavaScript. Or if you want something to start with try pasting this code.

let a = ()=>{
 console.log(message);
}
// see let becomes var
// and () => {} becomes function(..)
// lets try other things
//
let [red,green,blue] = [0,1,2];
// copying into a new object
var person = {
 name: "Jace",
 location: "MN"
}
/* 
// if you uncomment this, it will add a polyfill to do this
let copy = {
 ...person
}
*/

That should become something like;

var a = function a() {
  console.log(message);
};
// see let becomes var
// and () => {} becomse function(..)
// lets try other things
// spread
var red = 0,
  green = 1,
  blue = 2;
// copying into a new object
var person = {
  name: "Jace",
  location: "MN"
};
/* 
// if you uncomment this, it will add a polyfill to do this
let copy = {
  ...person
}
*/