Running An IT Startup in DFW

I wanted to talk about some of the challenges and lessons my business partner (Todd) and I have shared while running a small IT startup in the Dallas/Fort Worth area.

Let me go ahead and get this out… DFW is a great place to start a business. There are plentiful businesses with deep pockets that are growing fast. This leads to a healthy potential customer base that you could then sell your products to, especially for the way we decided to build our business.


Our Path

Todd and I decided to start Idea42 as a consulting company then transition it over time to being a Software as a Service (SaaS) company. We are right now running healthy as a consulting company, running profitably enough where we can support a team of people internally to build out internal offerings. With a software product nearing completion, we are well on the right path toward our end goal.

Now, the question some people may have about this path is, was it easy? My answer is “easy is relative” because in this industry, it’s really about who you know. More and more do I realize how true this is, and realize how naive I was, thinking I could make it in this industry based only on what I could do. I honestly was thinking I could just code my way to success without talking to people.

If you know enough people, this path is easy follow. But, if you don’t know a lot of people, this path is hard to follow because to build a solid consulting company, people have to trust you. This means someone would have had to work with you in the past to know what you are capable of OR see a constant stream of successes from your company to feel like you’re a safe bet. Idea42 is still young, so we don’t have a lot of successes in our company yet, because we haven’t done a lot yet. However, we have successes, but not enough to give people the warm fuzzies based on our company’s reputation alone. This is where the “who you know” part comes into play. People know Todd and I, they trust us, they trust we won’t lead them astray, so they give our company the chance to shine.


Our lessons learned

Something I learned later in life is that you cannot have success without struggle. Life is indeed like checkered pavement. And because I want others who will follow in our footsteps to also be successful and help them through some of their potential struggles, I will share some of the struggles that we had to overcome over the last 1.8 years.


Build out your network… It’s all about WHO you know in this industry

This is the most important thing you can ever do for yourself and your business. It’s something you hear every entrepreneur talk about it, and that’s because it’s the core piece of entrepreneurship. Networking is not my strong suite, believe me… However, I’m trying, and those efforts have led to success and potential leads for our company.

Have a coffee every once in awhile, talk with people, get to know them, get to know their business, get to understand their businesses problems, and try to present solutions to those problems. This whole process takes time and energy, so don’t let yourself fall too far behind, because it’s way harder to catch up. This leads me to my next lesson.


Never let working for your company become more important than running your company

This is a lesson that Todd and I are still trying to implement in our organization. You may have also heard this from others as “Being a business operator vs. Being a business owner”. Obviously, Todd and I started this company by ourselves, and were definitely “business operators” since we were directly involved with day-to-day operations of our business AND were still billing ourselves out to our customers. Together, Todd and I grew Idea into what it is today, and now the company, with the help of our team, is helping us soar. This now brings me to my next lesson.


Build a team of people you trust sooner rather than later

This is one of the most important lessons of them all, and something that EVERYONE will struggle with. Building a team of people you trust. I was once told by a good friend of mine that finding good employees is difficult, because no one will put in the effort you will put in to your company when it’s needed. I didn’t understand what he was meaning by this until now. So far, we have been lucky to have talented and motivated people working to make our company a success. Everyone has given 200% or more to make sure this company survives, thrives and grows. Currently, everyone we have brought on realizes that this isn’t a job, I wouldn’t even say that this is a career. Idea42 is an opportunity to make something out of nothing and be tied to that forever. The success of Idea42 means that we have all succeeded, and thus makes this a little different than a typical job. However, there’s a lot in that statement that Todd and I have to live up to, which leads me to my next lesson learned


Make sure you know what you are going to do, and how you are going to do it, before you start your business

Not too long ago, I was taught an important lesson. “Know Thyself”, because how can you figure out what you are capable of until you have contemplated on your own capabilities? How can you know what you need until you have contemplated on what you have needed?

It’s important for anyone wanting to go into business for themselves to understand the industry, understand their competition, understand how they want to do business, and have a defined culture and set of values that you will look for in everyone that you bring into your organization. Trust me, it’s way easier to sell your ideas to a person IF you have your ideas defined.



I’m not going to sit here and think that I know it all, because I don’t. However, I have learned a lot and I’m willing to share. If anyone wishes to ask me more questions about Idea42, about our struggles, our lessons, or whatever, please feel free to send me an email and I will do my best to answer.

Why a well put together Gulp file means everything

For any beginner developers out there running a server during their development phase there seems to be a commonality of constantly shutting down the rebooting the server. The reason why this happens so often is because while a server runs it doesn’t track any new changes made. So, now this brings us to the most annoying key combo of any developer, ctrl + C, up on the arrow key, then enter. While this seems like an easy combo image doing that over and over and over again during the development lifecycle to see what changes were made on the screen. This process can become very irritating over!

A solution for this is to use a task runner. While I’ve been using Grunt during my development cycle, I decided to switch it up for my next project and use Gulp. Right off the back a Gulp file just looks ascetically better than a Grunt file. Gulp to me reads more like english because it looks more like normal Javascript functions as compared to Grunt which has is own syntactical sugar. The project that I used Gulp for is a MEAN stack application. This being a project where I have to account for both the front and back end during development let’s get into how I set up my Gulp file for success.

While in the past I’ve used frameworks like Rails to help build my projects, using purely JavaScript to build this one was a little bit of a hurdle. While doing all the main things like concaving and uglifyingt my files the two things that really bulked up my Gulp file where Browser Sync and Nodemon. Let’s talk about Browser Sync first. Browser Sync is a library that allows your application to connect to a browser. While you can do a couple of different things with this the main thing that I used this library for was Live Reloads. If you aren’t familiar with what a live reload is, it is when your application detects changes and then automatically refreshes the browser without you having to type ctrl + R! This is great because just like starting and shutting down your server this process of constantly refreshing the browser can be just as irritating!

Now to deal with that dreaded shutting down and restarting the server. Enter Nodemon! What Nodemon does is monitor all server side filed on your application. Whenever Nodemon detects the a change in a file it automatically restarts the server and applies the changes to the file. Now in the Gulp file all you need to do is Nodemon to be run on the Browser Sync task and voila! You now have a strong Gulp file that will make your development life cycle a breeze because trust me. Those simple key combinations start to really build up over time.

Why To (sometimes) Rush Initial Design

Disclaimer–every agency, project, client, and designer are made differently and should not be treated all the same. The following is just one solution that I found unique. Written from a UI/UX designer’s perspective.

So you’ve just landed your agency a sweet gig, you’ve had your discovery meeting and you just sat back down at the office. There are several reasons why I believe (in certain situations) it is best to rush your initial design / wireframes and get it in front of your client as soon as possible.


1. Your Client’s Nerves

It is easy to forget that not everybody lives in this crazy project to project world that we do. In fact, unless the client is on retainer this might be their first experience with you, or even with the creative/software industry in general. If that is the case they may be very anxious to get comfortable with your work and process. If you have a discovery meeting and don’t show your client anything for several weeks, the client will probably experience some nervousness; are you going to make the deadline? Have you started working on it yet?, Did you just run off with their money? Also, the longer you wait, the more the client will expect. If you show them rough wireframes right off the bat, the precedence is set and the pressure bubble is popped. If you were to wait, the client may expect higher-fidelity mockups or finished products.


2. Your Nerves

The longer you wait, the more you feel that you should complete more prior to showing the client. However, its tough to begin working on details if the client hasn’t already ok’d the general layout/feel. The more time you invest before this initial design unveiling, the more is at risk for misunderstandings.


3. You Can Begin to Have Real Conversations

Having some design or wireframes can help drive productive conversations with the client. Post discovery conversations with clients without design will usually run stale, unproductive, and repetitive. But with design/wireframes/sketches, the client can begin to visualize their idea, and can help come up with new ideas, suggestions, and features. Designers should always do research on the client’s industry/field but the client will probably always have a better understanding of their own industry, and allowing your client to have part in these conversations is vital.



Where The “(sometimes)” Comes In

As I mentioned in the beginning of this post, agencies, designers, projects, and clients are not all made the same. If a client has hired you before and there is a trust there, the client may not want to see anything until it’s further along. Don’t always treat a client like a new client.

Sources — Andy Mangold from “On The Grid” podcast

Floating Labels– With Only CSS

Preface–I am not a developer. A designer, born and raised with some front-end experience, with limited JS knowledge, I like to find pure CSS solutions for fun.

Floating labels really took precedence with the launch of Google’s Material Design. They have been widely accepted because of solving the age-old UX argument between multiple form input field solutions.


What is a Floating Label?

A floating label is basically an inline label inside of an input field that floats above of the input box upon interaction. This enables the user to still see what the input field was originally requesting even after they have typed their answer.



Example of Google’s floating labels


Before these floating labels became popular, UX designers went back and forth between inline labels and right/left aligned labels. Inline labels were great for scan-ability and condensing information. But they fell weak after the user interacted with them and could no longer see what the input field was requesting. The floating label combines both of these solutions into an awesome user experience.




There are many ways to incorporate floating labels into your form. This way is CSS only (ofcourse) and it’s actually quite simple. So simple, in fact that you only really need 2-3 css classes.

My basic HTML:

The container div is optional. Be sure to add “required” to your <input> tag



This first class is mostly optional, the class for your <input> tag:



The second class determines how your <label> will look prior to user interaction:



The third and final class is just styling how the <label> will change upon user interaction:



And you’re done! Yay!

Below are some codepens that I put together to help you. The first one listed is a super basic example using the same 3 styles that I described above. The second is an example of how you can fit floating labels into your design.


Designers Finally Have a Spot at the Table… Now What?

Designers have been waiting for this moment for decades; principles like “design thinking” are finally becoming a forefront in many large businesses. Before companies like Apple, designers were not valued nearly as much as they are today. We have designed, photoshopped, and mocked up our way to the table. We’re finally in a place where we can help guide the company’s vision and culture.. so now what?

It can be daunting to suddenly be sitting in front of many high-level executives, all too busy to give you the time and energy you would like. So, how do you communicate to them and meet their needs, while still meeting the needs of the user?



Preparation & Research

As with any project the initial sprint should widely be research (personas, wireframing, concepting, sketching, list making, etc). The focus should remain on the end user; however, along with the end user personas, include an executive persona (you could call it “Stuckup Steve”, “Charlie Bigcheese”, “Egotistical Exec”, you get the picture). The purpose of this exec persona is twofold. It enables you to make design choices that reflect the large goals of the company and it also prepares you for the daunting meeting with execs. This way you won’t have to fabricate some BS about how changing the text to blue helps click-throughs; you would have already considered it and made the decision with their goals in mind.



Chances are these high-level folks haven’t even talked to an end-user in decades (if ever). It is likely they have become detached from design’s (specifically UX’s) goals. When I open a meeting I start by reminding the attendees of why we’re there. I quickly remind them of the meeting’s goals, project goals, and if applicable the current user struggles. This little opener should be no more than a few seconds. Remember, these folks think they don’t have time for you. This opener will put the goals in the forefront of their minds, and they will (hopefully) challenge your presentation on these goals.

As you begin presenting your work, or walking them through user stories, remember to relate to their objectives. It’s always important to keep your personas close by, but don’t stop with how it will benefit Midlife Mildred. Relate to the execs by stating how benefiting Mildred in this way will benefit their objectives (more click-throughs, signups, purchases, etc).

(Oh and it’s probably a good idea to leave the exec persona out of the meeting room, execs are fragile creatures and they may be offended if they see it.)



The execs are going to have something to say about your work. They couldn’t possibly hold an “o” title if they didn’t question everything, so be prepared. Your counter argument to a question can never be “because it makes this one user happy”… but it can be “because our testing shows that 35% of our users will be affected by it in X way and that’ll affect Y goal (Y goal being a goal from your exec persona).


 One last tip

If you start to realize that the productive part of the meeting is over, for example, the execs are questioning ridiculous parts of the prototype (“why is our URL…?”) then it’s time to put a bow on the meeting. You can do this by simply informing them of the next steps in order to move the project forward. I find that doing this provides an efficient and subtle way to wrap up the meeting so you can walk out like a champ.