We’re legally all the same company. Our parent company mission has always been that “We imagine a world in which everyone feels empowered to pursue a career in technology, fully supported through mentorship and with an emphasis on software artisanship.” When we were first starting out, we chose a DBA (Doing Business As – our legal name has always been jrbeutler, inc) of “EduSource” as a nod to that mission. Though we are every bit as much about that mission today as we were back then, we’ve recognized that our name can be confusing in the marketplace. That’s why we decided to add another DBA of “RoboSource” and use that for everything except our Earn and Learn Apprentice Training Programs. You can read more about the EduSource side of the business here.

That’s a fun story.

Back when Jason had a small company (called jrbeutler, inc.) that consisted of, well, just himself, he was consulting at a local logistics company and overseeing an outsourced team from India. At the same time, he was teaching a computer science class as an adjunct professor at Taylor University.

As the semester wore on, Jason discovered something surprising: the students were writing better, more concise, more maintainable code than the India team. An idea formed: what if we outsourced software-writing to local college students rather than overseas?

From there, the ideas snowballed. What if we brought in a few carefully selected students to work as a part of our development team? What if we hired them for two full years and spent the time training them to program in a real development environment, as a part of a real programming team? Thus, the “RoboSource” part of jrbeutler, inc. was launched.

In 2020, we started implementing Robotic Process Automation (RPA). In 2021, we realized that most of what we do is technology-assisted automation of some kind or another. Due to some brand confusion we’d experienced in the past, we made the decision to add the “RoboSource” brand as the main branch of the company – the one that does all of the actual implementation of projects. We’re keeping the “RoboSource” brand, but tailoring it to our Earn & Learn apprenticeship training branch.

That’s not the end! Check out this blog post to read the rest of our story.

At RoboSource, we’re anything but mundane. So when we convened our leadership team and tasked them with creating core values, we got some craziness. “Let’s base each one on a movie character.” “Or how about an obscure TV personality?” We got a lot of ideas. We had a lot of debate.

At the end of several meetings, we agreed on one thing: we wanted each core value to have a story. We wanted them to mean nothing to someone who just walked in off the street and everything to our team. We hoped by using core values that told a story, our team would remember them, internalize them, live them. Here they are:

1. Crownless King
Take ownership
Take responsibility
Give grace

2. Phalanx
Protect each other
Protect the team
March as one

3. Figure-it-Out Gene
Be curious
Be fearless
Find solutions

4. Kaizen
Keep improving
Keep changing
Make it better

Strange words, we know, but packed with meaning for our company. 

Well … yes, but that may not mean what you’re thinking. Automation by a robot, or computer bot, is really just using tools to train a computer to complete your process autonomously over and over again.

Sadly, there is no physical robot. Read more here.

Let’s find out! Schedule a free consultation here. We’ll have you show us your process, and we’ll let you know if it’s “automate-able.” If it is, we’ll get a quote together for you.

Sure! There are many kinds of process automation that don’t use robotics. For example

• A phone application that automates supervisors filling out forms that used to be done by hand, and automates the workflow
• A web application that automates a process for a team that observes various company locations by giving them step-by-step instructions.

Processes can be automated in many different ways. Using custom software is one way. Using data reporting tools is another. Robotic Process Automation (RPA) is just another tool in our arsenal.

Wandering if your process can be automated? Let’s schedule a free consolation to find out.

Since the software we write is custom, things will look differently from client to client, but our process stays generally the same. Here’s what to expect:

• Project Plan. Before we start any project, we want to make sure we can communicate the expected scope. So we always start with a in-depth meeting with our team. Coming out of this meeting, you’ll have a project plan, with milestones and a high-level estimate of what we expect the project to cost.
• Discovery. For each phase of your project, you’ll have a Discovery meeting with a business analyst. He/She will ask a ton of questions and sometimes watch how you work. Our goal is to become an expert at how that portion of your business runs.
• Plan. Once we feel like we have a handle on this portion of the project, we’ll create mock-ups of what we expect the software to look like. We’ll meet with you to make sure we are hitting your expectations. We may be back and forth in this phase several times. It’s important to take the time to get things right here, because changes are MUCH cheaper here than once development starts. Coming out of this phase, you’ll have high-fidelity mockups of what this phase of your project will look like.
• Development. Once the mock-ups seem right to both parties, our business analyst will start breaking the functionality into user stories, or small bits of development. Our software engineer teams will start in on actually programming your software.
• Testing. When the developer thinks the user story is complete, it goes through internal code review, where other developers look at the code to make sure it is following standards, etc. Then our testing department takes a crack at it, to make sure it works as expected.
• Demos. Occasionally, we’ll schedule demos with you to show you how things are coming along. There are points in development when there isn’t much to see (especially at the beginning) and points when there is a lot to show. Demos will help us make sure we are on track to your expectations. Sometimes, we’ll have you try to use the software, so we can see how things flow from a user perspective.
• Deployment and User Testing. Usually at the end of a phase of the project, we’ll deploy everything out to an environment where you can play with it. We’ll ask you to use it and send feedback to us. You’ll have a set amount of time during which we’ll fix any bugs you find.
• Communication. Outside of the occasional demo, you’ll get a weekly email with details of what we’ve done that week, along with a burn-down of your Points. Of course, we’re always available for a phone call too.
• Repeat. Once we complete a phase, we’ll cycle back to Discovery and run through everything again, iterating until the project is complete.
• Support. It’s important to realize that your software is a living, breathing organism. It lives out on the internet, which is constantly changing. Tools get upgraded. Your software will need regular support. If you do not plan to put money into supporting the software you just built, we recommend that you not build the software at all, as it will be an exercise of frustration for all involved. It’s important to know that you WILL need to put money into support once your project is finished.

The short answer: Yes. We can deliver your software on time.

How do we do that?

We use a tool called Enable Solutions, which gives us our Daily Layered Accountability (DLA) meetings. DLA is a way of checking in daily with teams to see how on-track we are with projects according to various metrics.

Enable engages every employee and aligns every team on delivering mission-specific outcomes in a culture of accountability and continuous improvement. More practically? Our DLA meetings keep us on track to making sure work is done in an expected timeframe. This is important for our development team – giving them an expectation of when we think work should be done and holding them to it is vital to meeting deadlines.

Want to know more about DLA? Read more here.

Here’s the thing. Software developers know software. They don’t know business (usually — of course there are exceptions). In general, our developers are writing software that will make your business more efficient. You want a business analyst (BA) involved in your software development process because they know business and understand process.

They say the devil is in the details. But really, the devil is in losing track of the details. And losing track is easy to do. But at RoboSource, we believe the essence of your business is in those defining details. Our BAs are tasked with collecting all of those details and keeping track of them. To build effective software, we need to know all about your workflow and how each piece of the process works in the whole. We need to know how you think, and how your employees think. We need to know about your revenue streams, about your decision-making, about how we can save you time, energy, and anxiety while we make your business model as smooth as possible.

The best software integrates seamlessly into your business. Having a BA involved in your project is how we make sure that seamless integration happens.

Meet our Business Analyst, Patric Welch.

Since this is a newer term in the industry, here’s what it means to us:

Using an Agile Contracting method, clients use Points to “purchase” a certain amount of functionality completed by a team. Though the vast majority of that work is done by a software developer, others help on the project as needed, including a project manager, a business analyst, an architect, and a quality assurance engineer.

We break any new features or projects into manageable chunks, which we then breakdown further into User Stories. The number of Points that a certain User Story “costs” depends on its size, which ranges from Youth Small (1 Point) to Large (13 Points).

We love Agile Contracting because we can form a true partnership with our clients, instead of hounding them about new scope (companies that use a traditional “fixed bid” method have to worry about this). When you want to add something to your project, you just “spend” the appropriate number of EduPoints. And we love that we can avoid the micromanaging that often occurs in “time and materials” contracts. If we feel like we need to bring in an architect, we do so, without haggling about an extra hourly rate. It’s all rolled in.