Praxent

In-house teams run our projects and oversee the core functions of the company, including design, development, product strategy, client relations, operations, sales, and marketing. We staff projects with in-house experts specialized in a variety of disciplines including product management, UX design, and software engineering.

Our teams consist of individuals based both in Austin, where we are based, and beyond, including throughout the US and Latin America. We have always embraced remote collaboration and enjoy the talent flexibility that our distributed teaming affords us.

1. Our rigorous hiring process for creating client-centered teams that deliver
We are slow to hire, so the teams we have today are the result of years of careful vetting and selection. Our interview process is so selective that we routinely have to evaluate 100 or more candidates before making a single hire. It’s been a discovery process of learning what individual team member characteristics and professional backgrounds deliver the most value to our clients.

While we invest significantly more in our interviewing practices than our competition, we feel strongly that this is the right approach. Through the process, we find principled professionals with the right combination of expertise and service attitude. We’ve created an atmosphere that keeps them motivated and engaged. As a result, we can confidently say that every Praxenter is intellectually humble, driven to make an impact and motivated to serve.

Having delivered over 300 successful projects, we have become very good at building effective teams that consistently overcome even the most complex obstacles.

2. Our fully-integrated services take clients from idea to implementation
Releasing a new digital product requires the detailed coordination of many work streams. It also requires expert thought applied to strategy, UX, UI design, technical architecture, software engineering, testing, and infrastructure.

Best-in-class digital products are designed and built by dynamic, multi-disciplinary teams. Asking a concrete or linear thinker to participate in the conceptual and strategic phases of a new product development effort can lead to misunderstandings. Meanwhile, relying on a high-level conceptual strategist to be responsible for on-time, on-budget delivery by date-certain can be disastrous.

For our clients, building an in-house team that possesses all of these skills is cost prohibitive and extremely time -consuming. Retaining them over the long-run requires an investment of time and money into management, professional development, and career planning.

Because we have all of these skill sets, areas of expertise and styles under one roof, we can staff them fractionally to fill the gap as client needs change. And finally, we don’t just partner on the conceptual and strategic work of creating products (professional research, testing, and user experience). We’ll also be here to build it when the time is right.


3. Repeatable delivery processes designed to reduce risk
64% of the software that is created today is waste. This shows up in features that are built but, sadly, never used. In addition, 68% of projects go significantly over budget or never finish.

While the details behind this research are complex, the solution is relatively simple – better business analysis. Projects that begin with thorough requirements validation, mature technical design and cross-team planning perform significantly better.

In our 18 years, we have delivered over 300 projects for clients ranging in size from startups to Fortune 50’s. To deliver these projects, we have built hundreds of teams consisting of different combinations of developers, designers, testers and business analysts. We have learned from experience how to set up a complex project for success. Our organizational design, management, and hiring practices reflect this learning.

While we don’t claim a specific industry focus, we have done a lot of work in real estate, healthcare, energy, and financial services over the past few years. Our portfolio also features work in government, education, hospitality, entertainment, automotive and business services.

Hundreds of our clients are repeat clients who have come back to us for:
● Ongoing maintenance on the projects we completed
● New additions to a product suite
● Significant new features for products we created for them in the past

The most critical component to formulating an accurate time frame estimate is the initial research and discovery phase and the subsequent prototyping and testing phase. Until we create a clickable prototype of the user experience, the requirements lack the clarity needed to estimate them accurately. Research shows that estimates produced before detailed analysis or prototyping can be off by as much as 400%.

Clients need to work through an initial discovery phase either with us or before they come to us. This phase includes:

● User research to validate the effectiveness and likely traction of the envisioned solution. This enables us to qualify feature ideas with real user input before we include them in the product roadmap.
● Clear value propositions and a market strategy for the product. For a product to be great at something, difficult decisions must be made to determine where to underperform relative to the competition. In most cases, we help clients develop or refine their strategy to prepare for the next phase.
● A product roadmap that lays out the features and capabilities of the system organized by functional area and release timeframe.

Using this information, we work together with clients to prioritize features and clearly define a minimum viable product. This step answers the question: what features do we need, at the minimum, to make this product successful with users?

We create a working prototype with those features and then do lean testing to validate the concept and refine as needed.

After this preliminary work, we can give an accurate cost and timeline estimate. Without research, prototyping, and testing, the project would move forward based purely on the assumption. Starting development without first testing assumptions puts the plan at high risk of going over budget and overdue should we discover problems with the initial concept.

Instead, we mitigate risk by validating the concept ahead of time. This weeds out incorrect assumptions before making a significant investment in development. From a place of confidence, we provide clients with accurate estimates and move forward into the roadmapping stage.

It depends entirely on the product. For clients working with us in a smaller capacity, it usually ranges from 2-4 months. These clients may be coming to us for project rescues, migration work or virtual CTO services. Most other projects require 4-8+ months with complex systems taking 1+ years.

Unless a client has already committed to a specific technology, we develop criteria for each client scenario. Some common criteria include:

● Client leadership. Does the client intend to build their own team or will we be maintaining the product for them long-term? If they intend to build their own team in the long run, we prioritize frameworks that they have experience working with.
● Use cases. What are the strengths or most common uses of a particular framework and how do those align with the requirements of this project?
● Bleeding edge. What sort of appetite do we feel is prudent for adopting a bleeding edge framework versus taking a more conservative approach? In the vast majority of cases, more mature frameworks have more tools and have been more thoroughly vetted; therefore, selecting them can make the team more productive.
● Future proof. What is the likely future of a particular open-source framework? Is there strong community or commercial support that favors one framework over another?
● Hiring. Do we need to focus on tools that have a strong developer following to support future team building and hiring?
● Retention. How likely is it that developers will remain optimistic about a chosen technology over the long run? If the open source community abandons a framework, developers tend to worry about pursuing a career dead-end by continuing on with that technology.

We have made the decision to remain technology agnostic, however, common architectures and technologies emerge again and again. In most cases, we are leveraging a microservices based architecture with a JS framework like React or React Native on the front end supported by a back end of .NET, NodeJS or Python.

In addition to React, Python and .NET, we have worked extensively in Angular, Ember, Java, PHP and multiple CMS flavors. An exhaustive list of our current skill set is listed, below.

FRONTEND
React
Angular
Ember
HTML5/SCSS
AMP
Electron CMS
WordPress
Drupal
SiteCore

DATABASE
PostgreSQL
MySQL
MSSQL
MongoDB

DevOps
Docker
Wercker
Jenkins
Kubernetes
Ansible
Octopus Deploy
Github
Rancher
Gulp/Babel
PhantomJS

BACKEND
C# on .NET
Python on Django
PHP on Symfony/Silex/Laravel
NodeJS on Express/Sails
Java

SysOps
Amazon Web Services
Google Cloud
Azure
Heroku
Linux: CentOS/Debian
Apache
Nginx
IIS
Solr
Reddis

MOBILE
iOS
Objective-C/Swift
Android
Java
React-Native
Xamarin
PWA
AppCenter

Due to compelling research on software estimating best practices, our preference is to prototype digital products before estimating cost and timeline visually. That being said, we recognize that a rough-order-of-magnitude (ROM) estimate is often a precursor to approving a prototyping project.

Using our custom-built ROM Estimator, we analyze technical requirements and compare the proposed product with comparable systems from our 18 years of experience. This exercise allows us to generate multiple staffing and project scenarios for the proposed product. We incorporate these steps into our ROM estimations:

• We identify separate work streams for the project based on logical and functional differences among the major activities.
• We perform a team-based estimating exercise to ensure the process isn’t overly biased by a single estimator.
• Depending on a variety of factors, we apply contingency buffers that account for unknowns.

There are two points worth emphasizing:

Estimating is not a one-time event.
We estimate projects repeatedly throughout their lifecycle. While estimating is not in itself complex, it can be counter-intuitive. Using the wrong estimating method at the wrong phase of the project can lead to massive cost overruns.

Change happens in every project.
For our clients and us, “done” is always a moving target. That’s because we build digital assets for changing environments with new competitive entrants and shifting market dynamics.

“How” is also a moving target because software teams aren’t static and the available tools are constantly evolving.

In this business, change is neither unacceptable nor an unlikely external event. It’s an expected rhythm often precipitated by the client’s business or user needs.

For these reasons, we have found that project pricing and planning methods must be designed to respond to change.

Praxent manages its projects using a fixed cost, variable scope model. This model enables our clients to make small scope adjustments during engagements without having to request and execute a formal change order. Effectively, software features are estimated in story points and can be swapped for features of similar size during the development phase.

Projects that only require UX design or prototyping typically start at a minimum of $30,000. Projects that involve design and development start at $150,000+.

We started projects that ranged from $30,000 for an initial phase to over $1.5M for a multi-year complex project.

Review sites have been a critical channel for increasing our brand awareness, helping firms in need of our services find us and driving high quality leads for our sales team.

● The conversion rate for traffic from Goodfirms.co is over 11% (site average is about 1.2%).
● Goodfirms traffic makes up about 0.5% of our traffic and over 4% of our goal conversions.
● Traffic from review sites accounts for about 13% of site traffic and 19% of goal conversions.